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FIELD OF THE INVENTION 



This invention relates to establishing customer accounts in electronic remote 
ordering systems, including mobile commerce systems. In particular this 
20 invention relates to establishing customer accounts in such systems wherein 
order fulfillment is by attendance of a customer at a physical merchant location. 



BACKGROUND OF THE INVENTION 



Electronic commerce and mobile commerce have not experienced the adoption 
rates once predicted. One barrier to adoption is the burden placed on 
prospective customers of creating and maintaining the required mobile 
30 commerce account. Another barrier is the lack of transaction security to prevent 
customer repudiation of transactions for the most common and economical forms 
of payment. In addition, electronic and mobile commerce schemes that require 
merchants and customers to adopt new/ technology generally take a long time to 
achieve a critical mass of penetration. 

35 
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A customer mobile or electronic commerce account should be usable for remote 
ordering of goods and services, and include identity information, security 
information, payment account infomiation and ordering infomiation for the 
merchant locations of interest. In prior art systems, account infonnation is either 
5 entered before the customer attends at the merchant's location or is acquired in 
real-time as the customer places the remote order and effects a payment 
operation. There is often no means for the merchant or the customer to verify the 
other's Identity In a timely and economical manner. 

I3 10 It is usually the merchant who bears the risk of poor authentication. Because of 
y such risk, merchants may not be in a position to accept certain types of payments 
H at all, having regard to regulatory restrictions, or to the rules of payment 

J associations, acquiring financial institutions, and payment processors. The risk 
of repudiation is aggravated by the fact that simply pushing an "I agree" button in 
Q 15 a browser, or similar methods commonly used in electronic commerce, does not 
n provide protection against later repudiation of the transaction by the customer, for 

if example because a payment by credit card is still considered a "card not present" 

111 transaction. 

20 These payment risks are material for electronic commerce merchants resulting in 
paying high interchange rates, fees, or needing to pay additional fees to payment 
guarantee services. Interchange rates and fees paid by merchants are almost 
always lower for "card present" transactions or other transactions where the 
merchant can verify the customer's identity and collect a signature on a payment 

25 agreement. For example, in the United States consumer protection regulatory 
restrictions make it difficult if not impossible for merchants to use low-cost debit 
payments, such as Automatic Clearing House (ACH) transactions without a 
previously signed contract with the customer. Processing contact documents, 
with signatures, through means such as the mail is clearly inconvenient for both 

30 merchants and customers, and can be a detriment to use of a remote ordering 
system. 
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Current practice also does not provide the customer witli protection against 
unauthorized use of their payment account. 

Prior art electronic commerce industry security standards either provide weak 
5 authentication or are difficult to implement and use. The well-known and widely 
used Secure Socket Layer (SSL) standard, promulgated by Netscape 
( www.netscape.com/ eng/ssl3). or the related Wireless SSL (WSSL) standard are 
easy to use and provides cryptographically strong security, but merchants and 
customers cannot authenticate one another. 

h 10 

Industry groups have also published standards for electronic transactions specific 

to mobile commerce. The Mobile Electronic Transaction Forum (MeT) 
|l (www.mobiletransaction.orq ) has published a complete framework for customer 

interfaces, transaction communication protocols and security for mobile electronic 
CI 15 commerce. The Mobile Payment Forum (www.mobilepaymentforum.org) and the 

now defunct Radicchio (www.radicchio.org ) each published security standards for 
*^ mobile electronic commerce transactions. Yet all such systems require 
fli customers, telecom operators and in some cases merchants to deploy special 

technology (typically based on smart cards or electronic security certificates) and 
20 the processes involved do not improve customer convenience. Further, these 

standards do not enable the direct authentication of customers for the benefit of 

the merchant, nor do they make the system easier to use for customers. 

The financial services/payment industry has also made attempts to facilitate 
25 electronic commerce and mobile commerce. The Visa payment association has 
developed the Secure Electronic Transaction (SET) and 3D SET ( www.setco.org ) 
standards. These technologies allow customers to be authenticated to 
merchants through the customer's financial institutions and protect merchants 
from transaction repudiation. However, they have not found favor with 
30 merchants, customers or financial institutions because of the complexity of the 



3 



technology required, which reduces convenience for both merchants and 
customers. 

The National Automatic Clearing House Association (NACHA) publishes 
5 operating rules in the United States for Eieotronic Funds Transfer (EFT). The 
NACHA Operating Rules document and electronic commerce risk management 
document (Risk Management for the New Generations of ACH Payments: 
Intemet, Electronic Check, and Telephone Payments) stipulate that a contract be 
signed by a customer before payments for electronic commerce can be made, 
tS 10 particularly for the WEB debit entry type. The suggested "best practice" is to 
P send this contract through the mail, making the process slow and mnning counter 
?! to the real-time nature of electronic and mobile commerce since it delays account 
W activation. Further, there is no simple way for a merchant to verify a customer's 

if! 

|l identity. To improve this situation NACHA has undertaken Project Action (ACH 
%i 15 Credit Transactions Initiated Online) to improve the security of online EFT 
transactions. However, customers are still required to go through a lengthy 
p registration process and require a special security certificate or smart card. 

:T I 

US Patent No. 4,960,981 to Benton and Mee describes an attempt to overcome 
20 the problem of timeliness of EFT account activation by using faxed fomris. 
However, this system has limited security capability and requires merchants and 
customers to have access to fax machines or fax servers. 

Attempts have also been made to facilitate electronic commerce through the use 
25 of electronic wallet systems allowing customers to set up a single set of payment 
accounts, which can be used with multiple merchants and do not require any 
special technology on the part of the customer. Companies such as iPIN 
(www.iPIN.com ). QPASS (www.apass.com ) and Microsoft through their Passport 
service (www.passport.com ) as well as others have introduced electronic wallet 
30 services. All of these services require the customer to enter a significant amount 
of information to set up an account and all lack a method to authenticate the 
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customer or incorporate capabilities to prevent the repudiation of transactions by 
customers. 

A system developed by Paybox (http://www.pavbox.de/international/enqlish.htmn 
5 and discussed in WO 0046768 to Entenmann relies on telephone network 
security, particularly that of the GSM system. While convenient for the customer, 
this system requires the merchants to have business relationships with multiple 
telecommunications carriers to prevent transaction repudiation. When the 
system is extended to other types of telecommunications, network security is 
ifj' 10 reduced. 

?! A system developed by PayPal fwww.pavpal.com ) and described in WO 
Ul 0205224 to Templeton and Bhargava and WO 0205231 to Sacks uses a scheme 
J; to authenticate the customer and verify that the customer is the legitimate holder 
15 of a payment account. While this system Is both reasonably secure and simple 
\M to use, account activation is not conducted in real-time. 

,|» 

P Prior art electronic commerce systems and mobile commerce systems, including 

those described in USP 5,991,739 to Cupps and Glass , USP 6,026,375 to Hall 

20 et. al., WO 00/45312 to Bigus, USP 5,710,887 to Ramen et. al. WO 01/25985 to 
Djupsjobacka et. al. WO 01/3298 to Dodson and Howe, WO 00/68859 to 
Borders et. al.), and EP 1 016 999 to Ogasawara, require a customer to enter full 
payment account information and browse extensive menus to select goods and 
services of interest to complete transactions. These systems provide various 

25 forms of preference or shopping list management to assist the customer with 
subsequent transactions, but such features are not available for the initial 
account setup. Further, these systems provide no method to authenticate the 
identity of the customer. 

30 Verifiable and trusted electronic payment is a required component of a fully 
capable electronic commerce system. The lack of such capability, the 
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requirement to use processes requiring additional technology or complex 
operations on the part of the customer or merchant, and the failure to enable the 
activation of payment accounts in real time all discourage the use of electronic 
commerce by both customers and merchants. 

5 

The present invention finds application in mobile and electronic commerce 
systems wherein order fulfillment is accomplished by the customer's attendance 
at a physical merchant location. One of the objects of the invention is to provide 
a reliable means of authenticating a customer in such a system wherein the 

1^^ 10 merchant can secure a signed contract or other reliable commitment instrument 

Q 

m from the customer. 
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Another object of the invention is to provide a reliable means of creating a 
customer account while minimizing the inconvenience to the customer. 

A further object of the invention is to provide a mobile or electronic commerce 
system that accommodates various levels of customer accounts, having regard 
to the amount of customer-related information collected from the customer and 
that accommodates corresponding levels of payment capabilities. 

These and other objects of the invention will be more fully appreciated by 
reference to the following disclosure and claims. 



25 SUMMARY OF THE INVENTION 

The invention finds application in mobile and electronic commerce systems 
wherein order fulfillment is accomplished by the customer's attendance at a 
30 physical merchant location, for example to pick up an order placed remotely and 
directed to the specific merchant location. 
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The invention has a number of aspects the implementation of which is enabled 
by a suitably configured remote ordering system used in association with in- 
person order fulfillment at customer-specified merchant locations. 

5 According to one aspect of the invention, a customer account is provisionally 
created when a new customer accesses the remote ordering system. The 
remote ordering system allows the new customer to remotely place an initial 
order. The remote ordering system processes the order through to the merchant 
location for fulfillment. Activation of the customer account (for the purpose of 
M 10 completing the initial transaction, or for the purpose of enabling future 
a transactions) is deferred until the customer attends at the merchant location to 
receive order fulfillment, at which time the signature of the customer is obtained 

H 

ii| in respect of a contract, or a summary thereof, governing the use of the remote 

if! 

l» ordering system. 

h 

i3 Upon the customer attending at the merchant location for fulfillment of an initial 
i! order placed remotely through a remote ordering system, the customer's identity 

CI may also be verified in person in addition to obtaining the signature of the 

mi 

customer is also obtained in respect of a contract governing the use of the 
20 remote ordering system. 

The foregoing aspects of the invention minimize the risks associated with initial or 
recurring payment from a non-authenticated customer. By securing a signed 
contract at the point of sale of the initial order, the invention provides a 

25 convenient mechanism for customers to authorize a merchant to use an ACH 
debit to the customer's Demand Deposit Account (DDA) using a WEB debit entry 
or similar payment type. This also provides a way for merchants and customers 
to initiate a trusted relationship. Once a contract has been signed and the trust 
conditions between the merchant and customer have been established, the 

30 customer can carry out a series of secure transactions with the merchant under 
the terms and conditions set forth in the contract. The subsequent transactions 
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conducted using the trust relationship can include the establishment of additional 
payment accounts or separate transactions to fund or make payment on an 
existing account. 

5 The signature can be used to verify the identity of the customer when checked 
against identification (typically photo identification is verified at point of sale). In 
addition, a signature provides a merchant, payment processor or service provider 
"proof of customer consent In cases where the customer attempts to repudiate 
the transaction. The initial payment is made once the signature on the contract 
!5 10 and the validation of the customer has been completed. The signed contract and 

0 authentication infomiation is stored and is then used as the basis for subsequent 

ai 

S transactions using the remote order system. 

According to the invention, a customer may register an electronic security 
lb 15 credential, which can then be used as a digital signature for subsequent payment 
% transactions. Registration is performed in the presence of the merchant and is 

1 therefore authenticated by the merchant. The authentication credentials or 
Jl digital signature in many cases will be attached or associated with the customer's 

wireless device. In other cases, the credential or signature will be attached or 
20 associated to a computer (i.e. a PC) or a telephone. It should be noted that the 
invention does not require the device carrying the electronic credential or used 
for providing digital signature to be physically present at the point of sale and that 
a piece of shared secret infomiation can be used as a surrogate. Authenticating 
the customer against this shared secret information serves the same purpose as 
25 using any other security credential or signature method at the point of sale. 

In the context of this invention, a digital signature is defined as any electronic 
credential that a user can present to a merchant or system operator to verify their 
identity. Numerous electronic authentication or security credential methods for 
30 electronic payment have been proposed and a number of these technologies 
have been put to use. Typically shared secret Information includes a password 
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(including Personal Identification Number or PIN) and often combined with a user 
name or other Identifier. Other suitable security credentials include biometric 
identification (including retinal scans, fingerprints and voiceprints), Public Key 
Infrastmcture (PKI) certificates, and shared secret key cryptographic certificates. 

5 

Alternatively, the contact and shared secret security data could be between the 
customer and a third party service provider. In this case a merchant acts as a 
facilitator or agent, activating the customer's account and verifying their identity. 
The third party service provider can then provide the customer with the ability to 
q 10 conduct secure transactions with merchants or other customers with whom the 
ii service provider has a relationship under the terms and conditions set forth in the 
'^1 contract. The process of establishing the verified trusted relationship with the 
m customer is the same in any case. 

CI 15 The security of a signed customer contract with verification of customer identity 
lil can be of great benefit to both merchants and customers and can enable many 
P types of electronic payment services including: 

1. micro-payments for digital content or other low value purchases 
20 such as at vending machines, 

2. using telecommunications billing systems to pay for purchases of 
goods and services, 

25 3. funding of prepaid telephone or other service accounts, 

4. electronic payment of bills, 

5. automated payment for fuel, other self service products or 
30 customer self checkout, 

6. providing the customer the ability to perform order and payment 
operations within a chain of affiliated merchants, and 

35 7. giving customers the ability to make payments to each other's 
accounts, a process often referred to as Person to Person (P to 
P) payments. 
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The merchant may also act as an agent for third party providers of the foregoing 
services or products, relying on the trust relationship built up with the customer to 
complete transactions involving such third party services or products. 

5 A system operator or payment processor would typically operate the system 
offering such services. The signed contract or service agreement between the 
customer and the operator would include terms required for these applications. 

In another aspect of the invention, a customer account is provisionally created 
when a new customer accesses the remote ordering system. The remote 
ordering system allows the new customer to remotely place an initial order. A 
customer identifier, which may be an arbitrary user name, is determined. The 
remote ordering system creates a provisional customer account and, without 
immediately an-anging for payment, processes the order to the merchant for 
fulfillment. Upon the customer's later attendance at the merchant location to pick 
up the order, the customer is identified to the merchant using the customer 
identifier and a form of substantially anonymous payment (such as cash) is 
secured from the customer. Upon payment for said order at said merchant 
location, the customer account is activated, using the customer identifier. In a 
further aspect of the invention, upon the customer attending at the merchant 
location for fulfillment of the order, the customer's identity is obtained and verified 
in person and the customer's signature is obtained in respect of a contract 
governing use of the remote ordering system. 

25 In yet another aspect of the invention, upon the customer's attendance at the 
merchant location to pick up the order, the customer is identified to the merchant 
using the customer identifier and information required to establish a payment 
account is obtained in relation to the customer. The payment account may be 
any form of payment account requiring electronic processing, including a stored 

30 value account, a debit account, a credit account, etc. 
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Some of the information required to establisli the payment account is obtained by 
electronically capturing information from means of payment or a payment 
credential tendered by the customer to the merchant at the point of sale, thereby 
enabling the creation of a more complete customer account. Relevant payment 
5 account information can be read from magnetic cards, smart cards, check drafts 
or other payment instruments, saving the customer the effort and potential errors 
of manually entering or orally providing this information. 

Alternatively, the infonnation is obtained by the customer providing the 
10 infomiation by direct entry, in writing or orally, at the point of sale. 

?j In yet another alternative, the information is obtained from marketing databases 

W containing likely customer prospects 

'I: 

!U 15 In a further aspect of the foregoing, the customer account is only activated after 
the customer's signature is obtained in respect of a contract governing the 
customer's use of the remote ordering system. In yet a further aspect, the 

'M 

l^l customer's identity is also verified in person. 

20 In the foregoing embodiments, the customer account is provisionally created 
contemporaneously with the placing of the initial order, but although the initial 
order is processed for fulfillment, the account is only activated following the 
customer's attendance at the physical merchant location to receive order 
fulfillment and to effect payment. More specifically, in the embodiments 

25 described above, the customer account is activated upon receiving cash or other 
anonymous payment, upon capture of additional information from means 
presented at the point of sale, or upon obtaining a signature on a contract. It will 
be appreciated that the moment of activation may be somewhat delayed, for 
example upon receipt of on-line payment authorization, upon settlement, upon 

30 later approval of the written contract, upon later verification of a digital signature, 
etc. 
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By completing activation of the account upon the customer's attendance at the 
point of sale, the invention provides a means for merchants to directly verify and 
authenticate the identity of customer before the first transaction is completed. 

5 

In another aspect of the invention, a customer attends at a specific merchant 
location served by a remote ordering system to place an in-person order. 
According to this aspect of the invention, the customer is invited to establish a 
customer account for the remote ordering system, and the customer's signature 
i;: 10 is obtained in respect of a contract goveming use of the remote ordering system. 

JJ In a further aspect, the customer's identity is also verified in person. 

m 

Ul In a related aspect of the invention, infomnation relating to the customer's initial 
order is captured from a POS temninal associated with the merchant to populate 
1. 15 preferences in the customer's account. 

In a further related aspect, a payment account is established by collecting 
9 information. The information may be obtained from the customer orally, in writing 

111 

or by direct entry by the customer. Alternatively, some of the information may be 
20 electronically captured from the means of payment or a payment credential 
tendered by the customer at the point of sale. In a further alternative, the 
information may be obtained from a marketing database containing identifying 
infonnation regarding customer prospects. 

25 The invention allows customers to create different levels of accounts with 
different capabilities. A customer benefits from being able to use a substantially 
anonymous account and can subsequently upgrade the account by adding more 
information as the need arises. Thus, customers can conveniently increase the 
capability of the account (for example when the service and merchant are 

30 considered to be sufficiently trustworthy). The following levels of customer 
account and associated capability are contemplated by the invention: 
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1. A substantially anonymous account enabling the customer to 
order goods and services. Despite the substantial anonymity, the 
account may be associated with electronically stored ordering 

5 preferences. The remote orders are paid for at the point of sale. 

2. A substantially anonymous account enabling the customer to 
order goods and services, offering electronically stored ordering 

10 preferences as well as payment through a substantially 

anonymous stored value account, funded from time to time at the 
point of sale. 

3. A full capability remote ordering account enabling the customer to 
15 order goods and services, offering electronically stored ordering 

preferences, and using electronic payment from electronically 
stored account information. 



20 To further improve customer convenience the invention makes maximum use of 
information that can be collected through minimal direct effort on the part of the 
customer before the first remote order and payment transaction can be 
completed. This allows an initial order for a new customer to be processed 
without delay. Additional information, if required for the type of customer or 

25 payment account desired, can conveniently be captured during the payment 
transaction for the initial order, thereby reducing the burden on the customer. 

In one of its aspects, the invention also contemplates both the creation and 
activation of a customer account following the placing of an order at a merchant 

30 location. According to this aspect, a customer who attends at a merchant 
location and has placed an order in person may be invited by store personnel to 
open an account to allow future orders to be placed remotely. The order data 
from the customer's order may be captured by an integrated POS system and 
combined with identifying infomiation provided by the customer, for example a 

35 telephone number, to create and activate an account for future use. The account 
may be of the substantially anonymous types described above or the fully 
capable type with electronic payment capability. In either case, a contract may 
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be presented to the customer at the point of sale for signing and the customer's 
identity can be verified in person. 

The integration of a remote ordering system with physical merchant locations at 
5 which orders are fulfilled in person makes the features of the invention feasible, 
including the identity verification in person at the point of sale, obtaining a signed 
contract, allowing provisional customer accounts to be created with completion of 
customer or payment account infomriation at the point of sale, as well as the other 
features identified herein. 

CI 

i5i It will be appreciated that the foregoing statements of the features of the 
invention are not intended as exhaustive or limiting, the proper scope thereof 
31 being appreciated by reference to this entire disclosure and to the substance of 
15 the claims. 

CI 

I BRIEF DESCRIPTION OF THE DRAWINGS 

if I 20 The preferred and altemative embodiments of the invention will be described by 
reference to the drawings thereof in which: 

Fig. 1 is a diagrammatic view of the remote ordering system used in 
association with the preferred embodiment of the invention; 

25 

Figs. 2A and 2B are a flowchart of a remote customer account creation 
process according to the preferred embodiment; 

Figs. 3A and 3B are a flowchart of an in-store customer account creation 
30 process according to the preferred embodiment; 

Figs. 4A to 4D are a flowchart of a customer account activation process 
according to the preferred embodiment; 
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Figs. 5A to 5D are a flowchart of a recurring payment process according to 
the preferred enribodlment; 
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Figs. 6A to 6N are a flowchart of an in-store order process according to 
the preferred embodiment; and, 

Figs. 7A to 7H are a flowchart of a telephone order process according to 
the prefen-ed embodiment. 



DETAILED DESCRIPTION OF THE PREFERRED AND 
, 15 ALTERNATIVE EMBODIMENTS 

2 

I The preferred embodiment of the invention is used to facilitate transactions with 
! remote ordering customers wishing to place orders and make payment for 

20 fulfillment and pick up at one of several merchant locations. The remote ordering 
customer interfaces with the remote ordering system, which is implemented 
through one or more servers, and places the order with the system by means of a 
mobile wireless device or other electronic interface device. 
The major system components of the remote ordering ("RO") system used in the 
25 preferred embodiment of the invention are illustrated in Fig. 1 . The RO system 
is based on the remote ordering system described herein and further detailed in 
our co-pending US Patent Application (application number not yet assigned) filed 
4 February 2002 entitled Remote Ordering System for Mobile Commerce. 
However it will be appreciated that many aspects of the invention are equally 
30 applicable to other embodiments of remote ordering systems that might be 
contemplated for use in conjunction with order fulfillment at physical merchant 
locations. 
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The major system components of the prefen-ed embodiment include: 



Transaction manager 10 
5 Payment engine 12 

Payment switch 14 
Stored value processor 16 
Security manager 18 
Settlement manager 20 
10 Report generator 22 

Database 24 and a database management system 
Order delivery system 40 
^'^^ Customer access gateway 42 

:si 15 The database 24 resides in non-volatile storage such as hard disk drives and 
includes: 

ill 

Customer accounts 28 
i: Merchant accounts 30 

CI 20 Transaction ledgers 32 

i^f Security information store 34 

Q Store information directory 36 

;g Data warehouse 38 

' 25 Not all of the components are necessary to the functioning of the invention. For 
example, a stored value processor 16 is desirable to facilitate payment, but such 
a payment option may not be critical to all embodiments of the invention. 

The principal components identified above are preferably housed and executed 
30 on one or more servers dedicated to the RO system of the invention and remote 
from the merchant store locations. Many of the components may be 
implemented as distributed sub-systems. 

External components interfaced to the RO system include: 

35 

External payment processors 56 
Location service providers 46 
Merchant extranet 48 
Merchant IT equipment 50 
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Customer access devices 52 
CRM system 54 
Marketing Databases 58. 

5 A summary of the interaction between these components is first presented in this 
section. 

The database 24 includes information specific to each merchant location, and 
organized in a stmcture that reflects the organizational structure and hierarchy of 
10 the merchant organization. This allows merchant-location specific functionality to 
be implemented in the RO system, which in turn allows customers to place 
15 orders with any one of the group of affiliated merchants serviced by the RO 
system. 

1=^ 15 Each merchant location is further associated with a merchant account 30 

'■I, allowing the RO system to tailor various remote ordering and post-sale processes 

CI 

Ul to the rules and conditions applicable to that merchant location. 

;f 

20 Summary of Interaction of Components of the RO svstem 

The following is an overview of the functions of the main components or sub- 
systems of the RO system. 

The transaction manager 10 controls the overall transaction flow and executes 
25 the required business logic. The transaction manager uses the services of the 
other components of the RO system, including the security manager 18, the 
payment engine 12, and the order delivery system 44. 

The payment engine 12 computes the price, promotional value, tip, fees and 
30 taxes under the control of the transaction manager 10. The payment engine 
receives payment authorization from either the intemal stored value processor 16 
or external payment processors 56 through the use of a payment switch 14. 
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The security manager 18 controls all access to data, reports and system services 
for the RO system, including access for both merchant employees and 
customers. The report generator 22 provides merchant personnel with reports on 
5 RO transactions from the data warehouse 38 and under the control of the 
security manager 18. The security manager uses a set a security protocol 
adaptors to accommodate the authentication protocols used by the various 
merchant and customer connections to the system. For data or system service 
access for personnel the merchant account security manager (18) authenticates 
fe- 10 the person and detemnines the permissions for data and service access. 
13 Authentication is done when personnel access the RO system over the merchant 
5i extranet (48) or through terminal or POS equipment (50) at a store location. If 
^§ personnel attempt to access data or services for which they are not authorized 
!p the merchant account security manager (1 8) will prevent them from doing so. 

Ul The transaction manager 10, payment engine 12 and security manager 18 each 
X make use of the records maintained in the database 24. This information 

?! includes the customer and merchant account information, store information 

ill 

directory 36 for each store location and for groups of locations, and security 
20 access and authentication information in the security information store (34). 
Certain transaction records are maintained in ledgers 32 and an archive of 
transaction details is maintained in the data warehouse 38. 

The RO system is adapted for use in association with a chain of affiliated 
25 merchants, for example in a franchise group. A security information directory 
and/or a store information directory are maintained wherein merchant location- 
specific information Is retained to allow the remote ordering system to be used 
seamlessly across the various merchant locations in the chain. Such infomnation 
includes for example information relating to order fulfillment capability, payment 
30 accounts, settlement protocols, menus, rules and administrative privileges. 
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For affiliated chains of merchants the security information store (34) is organized 
in a hierarchical manner. Merchant brands are divided into administrative groups 
that are generally organized along corporate organizational lines. A merchant 
brand can be divided into one or more geographic divisions and the geographic 

5 divisions divided into one or more geographic subdivisions. These subdivisions 
can include the territory of an individual franchise operator. There can be 
multiple levels of geographic subdivisions as required by corporate organizational 
structure. Geographic divisions or subdivisions are divided into individual store 
locations (518). Merchant employees and RO system administrators are 

10 organized into functions or "roles" that are used to simplify administration of 
permissions (for example to authorize refunds or to change merchant account 
information). These permissions are set through an administrative interface. 
Merchant employee permissions and roles are organized hierarchically in a 
manner that reflects corporate and ownership structure. Examples of levels in 

15 this hierarchy may include: 

1. Corporate, 

2. Geographic division or region, 

3. Group of store or franchise group, 
20 4. Store employees. 

Roles within these levels include: 

25 1 . Financial manager, 

2. Marketing or product manager, 

3. Operations manager, 

4. Franchise owner, 

5. Store manager, and 
30 6. Store employee. 

The security administration interface itself contains a hierarchy of security 
administration authority. Different levels within an organization can set the 
permissions and create accounts for personnel within their part of the company. 
35 Generally, security administrators can create or delete accounts for their level in 
the hierarchy or below. Thus, control of the administrative function is itself 
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hierarchical. As an example, administrators at a corporate level can set 
permissions for corporate employees at the corporate, regional or divisional level. 
Administrators at the regional or divisional level can set permissions for 
personnel within that division or region including store managers, franchisees or 
5 store owners. Administrators at the store or franchisee level can set permission 
for personnel directly associated with that store or stores. Levels and authorities 
for company-owned stores within a chain are generally structured differently than 
for franchisee-owned stores. The security administration interface is used to 
create or delete new merchant employee and store location accounts. Generally, 
u 10 security administrators can create or delete accounts for their level in the 
U hierarchy or below. For example, administrators at the store or franchise level 
1?^; will create or delete store employee accounts. 



The store infonnation directory (36) is also organized in a hierarchical manner. 

15 To allow customers to accurately remotely order and pay for goods and services 
agreement is required between the items, prices, promotional offers, service 
fees, and taxes offered at each specific store location and those shown in the RO 
system store Information directory. The benefits of remote ordering are defeated 
if items shown in the store information directory are not actually available at the 

20 store, or items desired by the customer are not listed in the store information 
directory. To ensure the store Infomiation directory has the desired content for 
each store location from time to time it can either be automatically synchronized 
with the store's POS system or administered manually or some combination of 
both. Nonetheless, the prices posted for the mobile commerce system need not 

25 necessarily be the same as those available in the store, but in general they are 
based on those prices. For example, the merchant may assess a surcharge or 
service fee. Alternatively, the merchant may offer discounts to encourage 
potentially lower cost electronic orders. Merchants in chains of associated stores 
are generally organized into an overall brand or brands (a corporate entity can 

30 own more than one brand), geographic regions or sub-regions, groups of stores 
(including franchisee-owned groups) and individual stores. As discussed below. 
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the store information directory 36 and the administration authority reflects such 
organizational structures. 

Within chains or merchant brands, geographic divisions, and subdivisions contain 
5 master menus or submenus. The use of these master menus simplifies the 
administration of the overall store information directory (36), by reflecting the 
authority or administration structure in the directory. Attributes and rules 
(required items, price ranges, item or category names, etc.) can be enforced from 
one level to the next as required. These master menus can contain information 



0 10 used in menus lower in the hierarchy. Using these master menus can thus 
ii speed directory administration at lower levels. Examples of global or regional 
H attributes and rules include the following, a) the name of the chain or brand, b) 

01 brand or region wide promotions, c) logos or trademarks, d) policy statements, e) 

•i- 

" terms and conditions for customer use of the RO system, f) transaction or service 
15 fees, g) Frequently Asked Questions (FAQs), h) service fees, and ih) display 

3 templates and objects for the brand or geographic region. To aid in 



administration and organizations levels in the hierarchical directory structure can 
be multiply linked to other levels beyond the ones immediately above and below. 
For example, attributes in a master menu can affect items at several levels: 
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1. 



The entire directory or menu, 



2. 



A specific menu or sub-menu, 



25 



3. 



A type or category of items, 



4. 



Required or non-required options for a type of category of items or 
compound items. 



30 



5. 



Specific items, and 



6. 



Required or non-required options for a type of category of items or 
compound items. 



35 
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The customer account (28) includes all information required by the system to 
allow the customers to place orders and make payments. The customer account 
(28) contains the payment account information organized by chain as well as for 
Independent store locations. The customer account (28) includes information (or 
5 links to information in other database records) to identify (ID) customers and their 
access devices. Preferably, these data will include: 

1 . A unique account number, 

10 2. User name or alias used for account access, 

3. payment wallet containing electronic payment account information 
as required, 



a 15 4. Identity information and information on Identity verification (shared 



secret information, signatures, etc.), 
5. Telephone number or other device identifiers, and 



U{ 20 6. Device type or capability information including device ID such as IP 

CI address, device capabilities for display, security, etc, and links to 

g; security information stored in the security information store (34). 

The customer account (28) includes a payment wallet containing all available 
25 payment account information in one or more purses. This payment information 
can generally include stored cash value purses (i.e. a prepaid account), 
promotional value purses or direct and payment account data. One or more cash 
purses (if present) contain information on the value in the account, the account 
used to electronically add funds (if desired by the customer) to the stored value 
30 purse and a list of the merchants or merchant chains accepting the account. 

The merchant account (30) contains all information, or links to other data storage, 
required for a store location to accept remote order and payment transactions 
and perform settlement through the RO system. The merchant location can be a 
35 part of a chain of affiliated merchants or a single stand-alone location. A 
separate merchant account is required for each store location in either case. The 
merchant account (30) contains basic store information including a store number 
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of other identifier, the store name or location name. The account also contains 
the geographic or other company divisions the store is associated with, and one 
or more brand identifiers associated with the store. The merchant account 
contains (or has links to) one or more financial account records showing all 
5 transactions at that store location and preferably including: 

1 . The merchant account number for that account, 

2. The type (settlement, promotional, etc) of account, 

10 

3. The account owner, or merchant of record, 

!s{ 4. The cun-ent settlement balance for that account, 

15 5. The financial institution holding the Demand Deposit Account, and 



ip 

■■fr 



'Ms 



6. The transaction history (or links to the ledger system) for that 
account. 



Q 20 7. Links to the specific store information directory (36), 



8. Links to the security infomnation store (34) for the employees at the 
store location, 

25 9. Account contact information, including the name of the account 

owner or primary contact, the contact telephone number, the 
contact's email address, the mailing address, and alternative 
contact information as may be required, and 

30 10. The payment types and customer authorizations accepted by the 

merchant location, and any authorization rules, such as value limits, 
need for signature capture, etc, for that payment type. 

The settlement processor 20 creates financial settlement files for each store 
35 location using the service. These files are transmitted at required time intervals 
through the payment switch (14) to the appropriate payment processors (56), 
who then settle funds to each merchants demand deposit account. In general 
each store location of a chain of merchant will have individual demand deposit 
accounts and will be settled separately. 

40 
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Customers using various types of wireless and fixed wired devices 52 to access 
the services of the RO system through the customer access gateway 42. 

The CRI\^ system 54 is used to perform customer support and relationship 
5 management functions using the records in the database, including the customer 
account 28 and data warehouse 38. The CRM system can be operated by a 
variety of entities including the RO system service provider, a financial institution 
or the merchants themselves. 

!«'■ 10 External Components 

il The RO system can use one or more external payment providers 56. The 

Uf services of these providers can include multiple payment types including credit, 

91 

I? debit, and stored value. 

L 15 

Q 

w One or more location service providers 46 are used to provide store location 
f= services and location directions for customers. These services allow customers 

S! using the RO system to find merchant locations of interest or to find the most 

I'll 

convenient location of a chain merchant. 

20 

The merchant employees use the merchant extranet (48) to access reports 
created by the report generator (22) and administer the RO system. Access to 
the extranet can be through the Intemet, telephone, or other suitable means. 

25 The order delivery system 40 transmits and confirms orders to the merchant IT 
equipment 50 at each individual store location. The merchant IT equipment (50) 
can include a variety of systems at the store location or distributed to remote data 
centers including, payment temninals, terminals dedicated to the RO function, 
integrated POS systems, self-service kiosks and associated peripherals. These 

30 systems communicate with the RO system through the order delivery system 44. 
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External marketing databases (58) are used as sources of information to pre- 
populate prospective customer accounts or to target prospective customers wiio 
are lil<ely to be interested in using the remote ordering service. 

5 Customers can access tine services of tlie RO system using a wide variety of 
wireless and fixed wired devices 52, including telepliones, text messaging 
devices and internet terminals connecting to the customer access gateway 42. 

Distributed Components 

i.,^ 10 

;;J The RO system may be distributed between multiple locations and entities. Even 

W individual components, including those shown in Fig. 1, may themselves be 

hj partitioned and distributed. For example, the customer access gateway 42 may 

|i be partitioned between any combination of telecommunications carriers and 

15 Internet Service Providers (ISPs). In another example, the security manager 18 

;t| may be under the control of and reside within a number of entities such as 

^! telecom carriers, ISPs and merchant or third party data centers. The database 

Q 24 may also be distributed such that different data tables (customer account 28, 

ill 

merchant account 30, store information directory 36) are under the control of 
20 various entities supporting the remote ordering service, such as ISPs, 
telecommunication carriers, banl^s, etc. In some cases, it might also be desirable 
to have, for example a directory of product offerings, that resides on some 
combination of merchant IT systems 50 at individual stores, centralized merchant 
data centers and the RO system service contractor. 

25 

Pavment Account Processing 

Electronic commerce requires payment that is secure for both the merchant and 
the customer. Payment can be electronic or cash at a merchant point of sale or 
30 electronic from a remote location. 
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The payment account is a component of the customer account (28), but is 
required only for customer accounts relying on electronic payment. A semi- 
anonymous account using stored value funded at the POS will only require 
minimal payment account information. Customers paying for purchases at the 
5 POS do not require any information in their payment account. 

Generally, a customer wishing to use a mobile payment account establishes it 
either when opening a customer account, or at some later time when the 
customer wishes to extend the available payment options. 

10 

:SJ Establishing the payment account may be done electronically from a remote 
location using an access device (52) connected through the customer access 
hj gateway (42) using one of a number of interface adaptors including: 

15 1. an Interactive Voice Response (IVR) interface or speech interface using 
ijl an Automatic Speech Recognition (ASR) system, 

: ^ K 

ei 2. through a web browser either on a wireless device or a fixed device, 

CI 20 3. a two-way pager or Short Message Service (SMS) device or Instant 
ill Messaging (IM) system, or 

4. using a terminal device or kiosk at the merchant's point of sale. 

25 

Part of establishing a payment account for stored value payments, credit 
payments or debit payments will usually be to establish a shared secret between 
the merchant (or remote ordering system) and the customer. The customer 
30 subsequently uses this shared secret to verify their identity when using such 
payment accounts. The shared secret is usually selected by the customer but 
may be automatically assigned to the customer by the remote ordering system. 

In one embodiment of the invention, during the customer account establishment 
35 process in connection with placing an initial order, the customer supplies a 
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be reduced, since the customer is required to present a pfiysical payment 
instrument and the merchant can verify customer identity and signature. The 
process flow for this account activation process is the same as that presented in 
the discussion above and shown in Figure 4A, 4B, 4C, and 4D. 

5 

The requirement to capture payment information is indicated on the printed or 
displayed information shown (1082) on the merchant's terminal or POS system 
(50). When the customer arrives at the point of sale (1084), the merchant 
employee requests the customer's payment instrument and captures the 
iji 10 payment account infomiation electronically using the appropriate peripherals 
5 attached to the merchant IT equipment (50). The IT equipment transmits the 
^^1 payment account information through the order delivery system (44) to the 
M payment engine (12) which requests an authorization (if real-time authorization is 
I' available) from the payment processor (56). If the authorization is received it is 
□ 15 sent to the merchant IT equipment where it is displayed. The merchant employee 
S then presents the printed service contract (1085) to the customer. Forms of 
I' suitable payment instruments include at least the following: 

ill 

1. a credit card where customer identity (account holder name), account and 
20 security information is collected by ether reading a magnetic stripe of a 

smart card, 

2. a debit card (on-line or off-line) from which the customer identity, account 
information and security information (including perhaps a competed PIN 
offset) are collected by reading either a magnetic stripe or a smart card, 

25 and 

3. a check draft, which is scanned to extract identity and account information. 

In some cases (particularly scanned checks) not all information will be acquired 
electronically. In this case a keypad attached to the merchant IT equipment (50) 
30 is used for the merchant employee or customer to enter the missing information. 
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In addition, the keypad is used to enter identity (teieplione number, device ID, 
etc.), payment account information or security information (i.e. a PIN). 

Once the payment account information has been captured and stored in the 
5 customer account (28), this information, usually combined with exchange of 
shared secret information, can be used for subsequent transactions without the 
need for the merchant or customer to handle the physical payment instrument 
again. 

S5 10 Issuing a Card 

%| In an alternative embodiment, the merchant can issue the customer a card at the 

Ijl end of the account activation process. The card can be used for identification 
and to facilitate payment processing during subsequent transactions. The card 

Q 15 can be combined with the use of shared secret information (e.g. a PIN) for added 

K security in the future. The card can use magnetic strip, smart card or bar coded 

4' technology. Altematively, a Radio Frequency Identification (RFID) device or 

jlj other type of electronic token can be issued. 

20 Once the customer account has been activated, using the processes discussed 
above, the merchant employee will activate the card using appropriate 
peripherals on the merchant IT equipment (50). The merchant IT equipment 
captures the card number, security information and any other identifiers and 
transmits them through the order delivery system (44) to the transaction manager 

25 (10), which passes the information to the security manager (18). The security 
manager verifies the information in the merchant account (30) and the security 
information store (34) and sends a confirmation of the activation back to the 
merchant terminal through the transaction manager (10) and order delivery 
system (44). If an error occurs in reading or activating the card, the merchant 

30 employee is instructed to try another card. Once the card is activated it is 
presented to the customer, who may be asked to sign it. 
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In subsequent transactions the card can be used to access a stored value 
account, loyalty points or other bonuses and promotions, or, possibly combined 
with shared secret infomiation, as a surrogate for other payment credentials (i.e. 
5 a checl< draft). The card can also be used to identify the customer to the 
merchant employee and query records of the customer's previous purchases. In 
subsequent transactions, the customer presents the card to a merchant 
employee, who reads it using appropriate peripherals of the merchant IT 
equipment (50). If required, the customer enters shared secret infomnation. The 
K 10 card information is transmitted through the order delivery system (44) to the 
CI security manager (18), which verifies the information in the customer account 
!y (28) and the security information store (34). The transaction manager then 
queries the customer account for payment, purchase and loyalty information, and 
,p transmits this infonnation back to the merchant IT equipment for display and use. 

;=i 15 

'{^ Limits on New Accounts 

iS Depending on merchant, payment processor and RO system operator business 
mies and the type of payment account being used by the customer, limits may be 

20 placed on a newly activated account. With some types of electronic payment 
instruments (e.g. credit accounts and PIN based debit accounts) an on-line 
authorization for payment is received in real-time or near real-time. In 
this case there is generally no need for limits on the account. With 
payment instruments that do not provide on-line authorizations (e.g. 

25 off-line debit or ACH) limits will be justified to limit the merchant's 
initial risk until an initial settlement is successful. Even if an 
on-line authorization is available limits may be justified to limit the 
risks from situations such as charge-backs, stop payment orders and accounts 
with Non-Sufficient Funds (NSF) that can affect ultimate settlement. The 

30 payment engine (12) enforces these limits using information queried from the 
customer account (28) and the merchant account (30). Examples of these 
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limits include activating the account to allow fulfillment of the initial 
order but not allowing any addition orders to be processed until initial 
settlement succeeds, or allowing subsequent orders to be fulfilled up to a 
present value limit until initial settlement has succeeded. 

5 

Even once initial settlement has succeeded limits may still be desirable 
until the customer has established a record of reliable settlement from 
their payment accounts (I.e. no charge-backs, stop payment orders or NSF). 
Limits will generally be increased in stages as the customer develops a history of 
10 reliability. 

Limits on Established Accounts 

Depending on system operator, payment processor and merchant rules, and the 
15 type of payment account being used, payment limits may be placed on or 
lowered for established customer accounts. Examples of cases where limits 
would be applied to a customer's account include a sudden change in the 
frequency or value of purchases, or a failure of settlement, including charge- 
backs, stop payment orders and accounts returned NSF. 

20 

The payment engine (12) enforces these limits using information queried from 
the customer account (28), the merchant account (30) and received from the 
payment processor (56) through the payment switch (14). Examples of these 
limits include placing a hold on all subsequent orders, or limiting the 
25 value or frequency of subsequent orders. 



Pavment Account Expiration 



Certain electronic payment account types (e.g. credit accounts) have 
30 expiration dates. In other cases, the customer may close a payment account 
and forget to update their payment account information in the customer 
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account (28). In this case, the payment engine (12) will typically be 
informed of the closed account situation by the payment processor (56) when 
a settlement fails. 



5 When the customer attempts to use an expired payment account or a closed 
payment account they are notified by the payment engine (12) through the 
customer access gateway (42) of the problem. The system processes the order 
In the usual manner, but when the transaction manager (10) transmits the 
order to the merchant IT equipment (50), through the order delivery system 

10 (44), infomiation is attached alerting the merchant employees that the 
customer's payment account has expired. This information will be displayed 
in electronic or printed from on the merchant's terminal (50). 

When the customer arrives at the store to pickup their order the merchant 
15 employee will ask them for new payment account information. This 
information is captured and the customer's identity verified using the 
processes already described in this document (see figures 3A, 3B, 4A, 4B, 4C, 
and 4D). Once a new payment account is available, the merchant employee will 
complete fulfillment of the customer's order. 

20 

Pavment Transactions 

Once a customer's payment account has been established, the customer can 
use that account for subsequent payment transactions. These transactions can 
25 be secured using the previously verified, captured and stored shared secret 
information or security credential. These transactions are executed under the 
terms and conditions agreed to and signed for by the customer during the 
account creation and activation process. The payment process flow is shown in 
Figure 5A, 5B, 5C, and 5D. 



30 



The customer initiates the payment process (1150) either in person at the 
merchant's store location or electronically. The RO system will apply any 
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promotional value (1 152) to the value or the customer's payment. If the customer 
chooses to use a direct payment (1154), but does not wish to use a stored value 
or direct payment account (1156) for an electronic payment the RO system 
transmits the customer order and a request to process the payment (1 158) at the 
5 merchant's store location once the customer arrives at the Point Of Sale (1160). 
During this process at the point of sale, the customer is then given the option 
(1162) of establishing an electronic payment account either electronically (see 
Figure 2A and 2B) or at the POS (see Figure 3A and 3B) (1164) as has already 
been described in this document. 

U 10 

;iJ If the customer is paying with a stored value account the stored value processor 
ll (16) determines if there is sufficient balance (1170) in the account. Depending 
on merchant mies, the customer may be allowed to spend their balance to zero, 
■|! below zero (effectively an over draft) or may need to maintain a minimum 
15 balance. If the balance is sufficient, the stored value processor debits the 
W customer's account (1172), returns a payment authorization to the transaction 
5; manager (10), which makes the proper account entries in the ledger systems (34) 

3 "' 

O and logs in the data warehouse (38). 

mi 

20 If the stored value account does not have sufficient balance and if the customer 
does not wish to fund the account electronically (1 174) the customer proceeds to 
the point of sale (1 176) to add funds to the stored value account. The customer 
presents the payment (1178) for the account funding to the merchant employee. 
The merchant employee processes the payment in the usual manner and enters 

25 the payment (funding) amount (1 180) into the terminal or POS system (50). The 
payment can be in the form of cash, a check, credit or debit. This payment 
information is transmitted through the order delivery system (44) to stored value 
processors (16) where entries are made into the customer account (28) and the 
ledgers (32) or data warehouse (38). 

30 
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The terminal or POS (50) software is designed to allow the merchant employee 
to automatically process these payments electronically, within the application or 
program (memory) space of the remote order application without the need to 
leave the RO application, process the payment in another application and switch 
5 back to the RO application. This reduces the burden on the merchant employee 
and speeds the process since no additional information needs be entered while 
switching between applications. This processing can include electronic check 
draft capture, capturing credit card information or debit card information from 
magnetic strip or smart cards and PIN entry and capture as required for the 
15 10 payment account. Electronic payment processing can be done using the 
?! faculties of the RO system in which case, the authorization request is transmitted 
\l from the terminal (50) to the RO system via the order delivery system (44) and 
III fonwarded to the payment processor (56) using the payment switch (14). 

Settlement for these funds is managed by the settlement manager (58) using 
CI 15 information in the ledgers (32) and merchant account (30). Alternatively, the 
S terminal or POS system (50) can use a separate connection (including "split dial" 
f connection) directly to the payment processor (56). In this case, settlement is 
ill managed in the same manner as all point of sale electronic transactions. 

20 Once the payment is processed (by whichever means), the employee enters the 
funding amount into the terminal (50), which transmits this infomiation though the 
order delivery system (44) to the stored value processor (16), which credits 
(1 182) the customer's account (30) and ledgers (32). The stored value processor 
(16) debits (1184) the customer's account (28) and makes entries in the ledgers 

25 (32) for the amount of the current transaction, and returns an authorization (1 1 86) 
for display on the terminal (50) for the merchant employee. 

An electronic payment can be used by the customer to either pay for an order 
directly or to fund a stored value account. When the payment engine (12) 
30 receives this request, it queries the customer's account (28) for electronic 
payment account information (1190). If shared secret information or other 
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electronic security credential is required (1192) the customer is asked to enter 
this information or use a previously authenticated electronic credential (1194) 
under the direction of the security manager (18) and the customer complies with 
the request (1 196). The request to the customer and the reply by the customer 
5 can be communicated through the customer access gateway (42) to the 
customer's access device (52) or through the order delivery system (44) to the 
merchant terminal (50). The security manager (18) verifies (1198) the shared 
secret information or security credential using information in the customer 
account (28) and the security infomnation store (34). If the verification fails, and if 
S 10 the customer has not tried too many times (1200) the customer is allowed to 
9 repeat the process. The number of retries allowed depends on the merchant and 
%l processor's business rules. 

P The payment engine (12) connects to the payment processor (56) through the 
Q 15 payment switch (14) and requests an authorization (1202). If the authorization 
i! succeeds (1204) the payment process is concluded with the payment engine 
=p making the appropriate ledger (32) and log entries in the data warehouse (38). If 
jfj the stored value account is being funding the payment engine (12) instructs the 
stored value processor (16) to make the required ledger (32) and log entries in 
20 the data warehouse (38) to credit (1206) the customer account (28). 

If the payment authorization fails the payment engine (12) asks the customer 
through either the customer access gateway (42) or the order delivery system 
(44) if they wish to try another payment account (1214). If the customer chooses 

25 not to try another account (1216) they are instructed to pay at the point of sale. If 
the customer does wish to try another payment account they enter (1212) the 
account information into either the merchant terminal (50) or their access device 
(52). If the customer has tried too many payment accounts (1210) the payment 
engine (12) (generally under direction of the security manager (18)) terminates 

30 the process. The payment engine screens the account information for fraud 
(1208) as has already been discussed in this document and the payment 
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authorization is repeated. If successful, the payment account information is 
stored in the customer account (28) for subsequent use. 

IN STORE ORDERING 

5 

The RO system allows both new and existing customers to place orders, use 
payment accounts and establish payment accounts while in the merchant's store 
location. A chart showing the in store ordering processes is presented in Figure 
6A, 6B, 6C, 6D, 6E, 6F, 6G, 6F, 60. 6H, 61, 6J. 6K, 6L, 6M, and 6N. These 
E 10 functions can be accomplished using a variety of merchant IT equipment (50), 
f including the merchant's integrated POS system (1300), an ordering kiosk (1302) 
%j or alternatively orders can be placed using a paper form. The ordering and 
!jf payment functions of the RO system are separated so that the customer can take 
=P advantage of either independently or use both together. Payment can be done 
15 anonymously (using typical POS processes), can be from an anonymous stored 
i: value account (an account with no name attached and funded with cash at the 
|» POS) or using electronic payment account information stored by the RO system 
SJ In the customer account (28). These capabilities maximize the customer's 

choices and convenience when setting up or using an electronic or remote 
20 ordering account. To further maximize customer convince, order information is 
stored in the customer account (28) for use during subsequent transactions. 

Paper Form Orders 

25 When ordering from a paper form, the customer acquires the form from a display 
in the merchant's store location (1304). Alternatively, the customer can use a 
form acquired during a previous visit or printed from electronic form (obtained by 
email or a web site). The customer enters their telephone number onto the fomn 
(1306). It will be understood that an email address, device identifier or other 

30 unique identifier can be used as an alternative to the telephone number for this 
purpose and throughout this document without any substantive changes in the 
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invention. The customer then codes (1308) the items they wish to order on the 
form, along with any options or modifiers (1310). The customer presents the 
form to a merchant employee (1312). The employee can then scan the form 
(1314) with a scanner attached to the terminal or POS system (5), from which the 
5 encoded order information is transmitted to the RO system through the order 
delivery system (44). Alternatively, the merchant employee can fax the form to 
the RO system through a fax server attached to the order delivery system (44) 
where the coded information is scanned (1316). In yet another alternative, the 
customer can directly fax the form to the RO system. 

10 

□ Once the information on the form has been captured the store location is 
extracted (1318) from the form by the order delivery system (44). The store 

U| location code can be preprinted on the form. In an alternative embodiment, the 

if « 

J order delivery system (44) extracts the store location from the telephone number 

■^^ 15 of the incoming fax call or network identifier of the merchant IT equipment (50). 

y The transaction manager (10) reads the telephone number coded by the 

?J customer from the form and determines if there is an error reading the number 

iff! ^ 

P (1320). The transaction manager (10) then looks up the customer account (28) 

111 

by telephone number (1322) and determines if this is a new account (telephone 
20 number) (1324). If the telephone number is a new one the transaction manager 
(10) will create (1326) a new customer account (28). The transaction manager 
verifies (1328) that the items ordered, options and modifiers are available in the 
store specific infonnation directory (34). 

25 Account Population and Pavment 

Once the customer account (28) has been established it is populated with 
customer order preferences and payment information as desired by the 
customer. The customer communicates with the RO system using their access 
30 device (52) connected through the customer access gateway (42), or using the 



49 



merchant terminal, POS system or self service kiosk (collectively merchant IT 
equipment 50) connected through the order delivery system (44). 

The order information is saved by the transaction manager (10) in the customer's 
5 account (28) as an ordering preference (1332). The payment engine (12) 
computes the price, tax, tip and service fee (1334) for the specific store location 
using information In the store information directory (36) and merchant account 
(30). Based on customer choice coded on the forni, electronic payment can be 
used (1336). The customer is given the option (1338) to use a promotional code 
M 10 or account number, which they enter (1340) and is transmitted to the RO system 
% by the merchant IT equipment (50), through the order delivery system (44) to the 
'S payment engine (12). The payment engine (12) credits the customer's account 
uj for the value of the initial offer (1 342). The payment engine computes the price, 
*S tax, tip and service fee for the customer's order and transmits the payment 
^ 15 amount to the merchant terminal or self-service kiosk (1 344) where the amount is 
Jl displayed. The customer Is given the option to establish a stored value account 
9 (1346). 

' If direct electronic payment is being used the payment instrument is requested 

20 from the customer (1400). The customer presents the payment (1402) to the 
merchant employee who scans it on the terminal (50) or the customer uses a 
card scanner or reader on the self-service kiosk (50). The payment account 
information is transmitted though the order delivery system (44) to the payment 
engine (12). The payment engine and transaction manager (10) creates the 
25 payment account in the customer account (28) using the process in Figure 2A 
and 2B (1404). The customer identity is verified and the account activated 
following the process in Figure 4A, 48, 4C, and 4D (1406). 

For cash payments the payment engine (12) transmits the payment amount 
30 though the order delivery system (44) to the merchant terminal (50) or kiosk (50) 
where it is displayed for the merchant employee (1408) or customer. The 
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customer presents cash to the merchant employee or inserts the cash into a bill 
acceptor on the kiosk (50) (1410). The employee enters the cash amount into 
the terminal (50) (1412). The cash payment amount is transmitted from the 
merchant terminal (50) or kiosk (50) through the order delivery system (44) to the 
5 payment engine (12) (1414). The payment engine (12) enters the cash payment 
information into the ledger records (32) and logs in the data warehouse (38). 

The payment engine (12) transmits a confirmation of the customer's order (1416), 
if required, through the order delivery system (44) to the merchant terminal (50) 
1:,^ 10 where it is displayed and confirmed. Once the order is confirmed the transaction 
% manager (10) saves the preference (1418) for future use as an ordering convince 
ffll by the customer in the customer account (28). The transaction manager (10) 
! J locks down the transaction (1420) by making entries in the merchant account 
m (30), ledgers (32) and logs in the data warehouse (38), and the employee fulfills 
15 the customer's order (1422). 

'3 Order Error Processing 

pi 

When an error in a customer order occurs, the transaction manager (10) 
20 identifies the error type and creates an informative error message (1430). The 
message includes information instructing the customer how to fix the error. The 
error message is transmitted through the order delivery system (44) to the 
merchant terminal (50) where it is displayed (1432) for the merchant employee 
and customer. If the customer chooses to correct the error (1434) they fill out 
25 another form and submit it to the merchant employee (1436) and the order entry 
process is repeated. 

Subsequent In-Store Orders 

30 Customers have the option to place subsequent orders using previously coded 
orders saved in the customer account (28) while in the store (or using forms 
faxed from another location). These orders can be repeat order of previously 
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coded preferences and can be charged to existing payment accounts. 
Information on orders with new items, options or modifiers is saved as additional 
order preferences for future customer use. 

5 The order information is transmitted through the order delivery system (44) to the 
transaction manager (10) where the coded information is extracted (1560). 
Alternatively, infomiation scanned from the fomn can be transmitted. The 
transaction manager (10) verifies (1562) against the store specific infomnation 
directory (36) that the Items, options and modifiers selected are available at the 
M 10 store location. The transaction manager (10) queries the customer account (28) 
S information (1 564) using the telephone number or other Identifier. 

m 

Ul If a preference number for the order has been coded (1566) on the form by the 

|J customer the order infomnation Is saved with that number (1568). If no 
L 15 preference is coded the order information is saved as the first preference in a list 

W (1450) as a default. The order infomiation is saved (1452) by the transaction 

% manager (10) under the preference number for the future ordering convenience 

O of the customer in the customer account (28). 

ill 

20 The payment engine (12) computes the price, tax, tip and service fee for the 
order (1454) using Infomnation in the merchant account (30) and the store 
information directory (34). The payment is processed using the process shown In 
Figure 5A, 5B, 5C, and 5D (1456). The payment authorization is transmitted 
(1458) through the order delivery system (44) to the merchant terminal (50) 

25 where it is displayed for the merchant employee. If the payment requires a 
signature for authorization (1460) the customer is presented with and signs the 
authorization slip or places a signature on a tablet for digital capture (1462). The 
merchant terminal (50) prints the signature slip. The signature slip Is archived or 
the digital signature is archived (1464) In the data warehouse (38). The 

30 employee enters a verification or confirmation code (1466) into the merchant 
terminal (50), which transmits the verification code to the payment engine (12) 
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through the order delivery system (44) where it is stored in the data warehouse 
(38). The transaction manger (10) then locl^s down the transaction (1468) and 
maizes the required entries in the ledgers (32) and logs in the data warehouse 
(38). The employee fulfills the customer order (1470). 

5 

Establishing a Stored Value Account 

The RO system supports options for the customer to establish, fund and use a 
stored value account for payments. The stored value account are established, 
10 funded and used either electronically (generally from a remote location) or in 
ii person at the point of sale. Funding of the account at the point of sale can be in 

y cash, check or using an electronic means. 

ui 

|: When the customer initiates establishing a stored value account they are offered 
h 15 the option of funding with cash or electronically (1480). When the customer 
wishes to fund with cash, they proceed to the POS and present cash (or check) 
J to the merchant employee (1488). The employee enters (1490) the cash 

S! amount taken into the merchant terminal (50), which transmits (1492) the cash 

ry 

amount to the stored value processor (1 6) through the order delivery system (44). 

20 

If electronic funding is to be used, the customer can perfomn the funding using a 
wired or wireless access device (52), at a self-service kiosk (50) in the store or at 
the POS using the merchant IT equipment (50). The customer chooses the initial 
funding amount (1482). The funding account infomiation is captured (1484) 
25 using the process shown in Figure 2A and 2B or Figure 3A and 3B and the 
customer's identity is verified and the account is activated (1486) using the 
process shown in Figure 4A, 4B, 4C, and 4D. 

Once the account is funded the stored value processor (16) establishes (1494) 
30 the customer's stored value account in the customer account (28) and makes the 
required entries in the ledgers (32), logs in the data warehouse (38), and debits 
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(1496) the account for the amount of the purchase if any. The payment 
confirmation (1498) is logged by the stored value processor and sent to the 
merchant temninal (50). 

5 Optionally, the merchant employee can activate a stored value magnetic or smart 
card (1500) for the customer as has previously been discussed. 

Orders with Integrated PQS Svstem 

S 10 Employees can assist customers in creating accounts, for making electronic 
5 payments with their accounts and ordering goods and services using an 
integrated POS system (50). The integrated POS system communicates order 
and payment information directly with the RO system over a data network 
'$ through the order delivery system (44). 

Mi When the customer places an order with a merchant employee they have the 
J option (1510) to use or establish a remote ordering account. If they choose not 
M to use an RO account their order and payment is processed in the conventional 

manner (1512) following the merchants normal procedures. 

20 

If the customer does wish to use an RO account the merchant employee asks the 
customer for their telephone number or other identifier (1514), which the 
employee enters (1516) into the POS temninal (50). The POS terminal transmits 
the identifier information through the order delivery system (44) to the transaction 
25 manager (10) where a query of the customer account (28) database is made to 
determine if the customer already has an account. The RO system transmits the 
customer account infonmation (if any) to the POS system. 

If this Is a new customer (1518), the customer dictates their order to merchant 
30 employee (1520), who enters the items ordered along with options and modifiers 
into the POS system (50) (1522) following normal POS procedures. The POS 
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system then transmits the order information and telephone number to the 
transaction manager (10) (1524) through the order delivery system (44). The 
order delivery system extracts the store location (1526) either from data coded in 
the message or from the network address or dial connection number used. 

5 

The payment engine (12) then computes the order price, tax, tip, and service fee 
(1528). The payment engine transmits the payment amount through the order 
delivery system (44) to the POS system where the information is displayed 
(1530). The customer is given the choice of paying with cash or electronically. If 
= 10 the customer chooses cash the payment is processed and order fulfilled in the 
! manner already described (1408, 1410, 1412, 1414, 1416, 1418, 1420, 1422). If 
the customer chooses electronic payment, the payment is processed and the 
order fulfilled in the manner already described (1400, 1402, 1404, 1406. 1416, 
1418, 1420. 1422). 



" 15 



The ordering preferences (based on pervious orders stored in the customer 
account 28) for recumng customers are displayed on the POS system (50) 
(1552). If the customer wishes to order a preference (1554) the customer tells 
the employee their preference (1568) and the employee enters the choice into 
20 the POS system (1570). The POS system transmits (1572) the order preference 
to the transaction manager (10) through the order delivery system (44). 



If the customer wishes to place a new order they tell the merchant employee 
which items, options and modifiers they wish to order (1556). The merchant 

25 employee enters the customer order into the POS system (50) (1558). The 
customer then selects a preference number for this order, which the employee 
enters into the POS system (1560). The order and preference number Is 
transmitted from the POS system, through the order delivery system (44) to the 
transaction manager (10) (1562), which saves the preference and order 

30 information in the customer account (28). 
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Payment is processed and the order fulfilled following the in store payment 
process to be described below. 

In-Store Kiosk Order 

5 

Customers can create accounts, place orders and make payments using the RO 
system through a self-service kiosk (50) at the merchant's store location. The 
kiosk can be equipped with a magnetic card or smart card reader for electronic 
payment and a bill acceptor for cash payment. As has already been described, 

yk 10 customers can use the self-service kiosk to create and fund stored value 

% accounts. 

hi If this is the customer's first use of the system (1590) the customer is asked if 
fl they wish to create a remote ordering account (1596). If they do not wish to 

15 create an account the customer enters their order selection (1600) using the 
id interface on the kiosk (50). The kiosk transmits the order to the order delivery 
^3 system (44), which transmits (1 602) the order to the merchant terminal (50). No 
iil transaction processing by the RO system is required. In an alternative 
■ embodiment, the kiosk can directly transmit order information to the merchant 

20 temninal or PCS system. The customer proceeds to the point of sale (1604) for 
order pickup and payment. 

If the customer does wish to create a remote order account the customer enters 
their order (1598), including items (goods or services), options and modifiers, into 
25 the interface on the kiosk (50). The order is transmitted to the transaction 
manager (10) through the order delivery system (44). The processing and the 
payment for in-store initial orders has already been described and starting at item 
1334 on Figure 6C. 

30 Recurring customers log into the kiosk (50) (1592) by entering a telephone 
number, a user name or other identifier or using a magnetic card, bar-coded 
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card, or smart card. The kiosk (50) transmits a request through the order 
delivery system (44) to the transaction manger (10) to query customer account 
(28) records (1592) and then transmits account infomiation back to the kiosk. 
The kiosk presents the customer's ordering preferences (1610) to the customer. 
If the customer wishes to use a preference (1612) the customer selects the 
preference (1614) of choice. The preference selection is transmitted to the 
transaction manager through the order delivery system. 

Alternatively, the customer can make a new order selection (1616) (for goods 
and services) including items, options and modifiers, using the interface on the 
kiosk (50). The kiosk transmits the order though the order delivery system (44) to 
the transaction manager (10). The transaction manager (10) verifies through the 
location specific store information directory (36) that the order corresponds to the 
items, options and modifiers are available at that location. If there is an en-or, the 
error is transmitted back to the kiosk and the customer asked to correct the error. 
Once the order is accepted the customer is asked to assign a preference number 
to the order for future use (1620), which is transmitted through the order delivery 
system (44) and saved by the transaction manager (10) (1622) in the customer 
account (28). Payment and order fulfillment for in-store orders for existing 
customers are discussed in the next section. 

In Store Pavment Process 

The RO system offers customers with RO accounts multiple payment options 
while they are in the merchant's store location. These choices include credit 
cards, debit cards, checks, cash, and stored value accounts managed by the RO 
system. These payments can be made through a merchant employee at the 
POS merchant IT equipment (50) or at a self-service kiosk (50). 

The transaction manager (10) receives t the order and passes it to the payment 
engine (12) which computes the price, tax, tip and service fee for the customer's 
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order (1624). The payment engine (12) then transmits the payment request and 
order (if required) to the merchant terminal or l^iosk (50) (1628) through the order 
delivery system (44). 

5 The customer is given the option to pay with cash (1630). The customer 
presents cash to the employee or places cash into the kiosk (50) bill acceptor 
(1638). If the employee is processing the payment they enter the cash amount 
into the terminal (50) (1640). The payment information is transmitted (1642) 
through the order delivery system (44) to the payment engine (12), which makes 

Pi 10 appropriate ledger (32) and log entries in the data warehouse (38). 

§ 

SI If electronic payment is to be used, the merchant employee or kiosk (50) 
!ii requests payment (1632) from the customer. The customer presents the 
■I' payment instrument to the employee or swipes the payment card with the kiosk 
SI 15 (1634). The electronic payment is then processed following the flow shown in 
]i! Figure 5A, 5B, 5C and 5D. 

i^l Once the payment process has been completed, the transaction manager (10) 
locks down the transaction (1644), making the required ledger (32) and log 
20 entries in the data warehouse (38). Once payment authorization has been 
received at the temiinal (50), the merchant employee fulfills the customer's order 
(1646). 

TELEPHONE ORDER PROCESS 

25 

The RO system provides customers with multiple options for creating accounts, 
placing remote orders, and performing payment electronically. This section 
explicitly describes the process followed for account creation, ordering and 
payment by customers using a wired or wireless telephone. Customers can use 
30 a variety of access devices (52) for access to the RO system, including wired and 
wireless Internet devices and wired and wireless telephones. Altematively 
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customers can use wired or wireless short message devices (e.g. two-way 
pagers), devices supporting the Short IVIessage Service (SIVIS) or an IM system. 
Electronic connections to the customer access gateway (42) can be used from a 
remote location or while the customer is at the merchant's store location. The 
5 basic telephone order process flow is shown in figure 7A, 7B, 7C, 7D, 7E, 7F, 7G 
and 7H. A local area wireless base station can be used for connections at the 
store location. It will be clear to those skilled in the art that the processes and 
functions discussed here will be nearly identical if the customer were using a 
wired or wireless interface device or other electronic interface device. 

S 10 

iS Connection and Store Identification 

M 

y When a customer wishes to place an order or perform another operation through 
i the RO system they dial a merchant number (1700). The customer access 
U 15 gateway (42) attempts to detect the customer's telephone number (using 
y Automatic Number Identification, ANI, or other methods) (1702). The transaction 
J manager (1 0) then identifies the customer and queries the customer account (28) 
S (1704). 

20 The customer access gateway (42) extracts the dialed digits (1706) (using the 
Dialed Number Indication System, DNIS, or other method). The transaction 
manager (10) detemnines if the number dialed corresponds to a local store 
number (1708) and if so uses this information to identify the location (1710). 

25 If the customer access gateway (42) is not able to identify the customer's ANI 
(1702), the customer is asked to enter their telephone number (1752). If a PIN or 
security code is required (1754) the customer is asked to enter their PIN (1756). 
The customer enters the PIN (1758) and the security manager (18) verifies that 
the code is correct (1760) by querying the customer account (28) or the security 

30 information store (34). If the there is not agreement, and if the customer has not 
made too many tries (1 762), the customer can repeat the process. The number 
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of tries allowed is dependent on the merchant's and system operator's business 
rules. It should be clear that a log in procedure using user name (or other 
identifier) and password (or other security credential) can be used as an 
alternative, with the best choice depending on the characteristics of the user's 
5 interface device. 



If the customer has not dialed a number specific to a specific store location 
(1708) and if the customer is not using a preference which includes location, the 
customer must select a store location for their order. If the customer knows a 
10 store location code (1770) or other identifier they can enter it (1772). If not, the 
p transaction manager (10) will present location choices (1774) through the 
;Ji customer access gateway (42) and the customer can select the location of 
Ml interest (1776). It will be understood that the same process is used with data 
|! connections; only the forniat of the user interface is different. 
" 15 

Ul Ordering Process 

: {; 

The transaction manager (1 0) determines if this is the customer's first use of the 
system (1 714) (or does not have a customer account 28). Recurring customers 
20 are given the option of hearing their ordering preferences (1716), and if so, the 
customer access gateway (42) presents (1718) these preferences. 



The customer is given the option to create a preference, edit an existing 
preference or place an ad hoc order (1720). The customer then selects or edits 

25 (1722) the items, options or modifiers of choice for the preference or order. The 
order and preference are transmitted through the customer access gateway (42) 
to the transaction manger (10) verifies (1724) through the specific store 
information directory (34) that the items, options and modifiers in the order 
correspond to the offerings at that location. If not, the customer Is asked to edit 

30 the order. If the customer is creating a new preference, they are asked to assign 
a number to this preference (1726). The transaction manager (10) saves this 
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preference in the customer account (28) under the number specified. The 
customer then places the order (1727). If the customer desires (1720) they can 
select an order preference (1728) directly. In either case the order or preference 
is transmitted through the customer access gateway (42) and passed to the 
transaction manager (10) for processing. 

It will be understood that the same processes described in this section can use 
data connections as an alternative; only the forniat of the user interface is 
different. 

Payment and Order Fulfillment 

Once the customer has placed an order their payment is processed flowing the 
flow shown in Figure 5A, 5B, 5C, and 5D (1730). Once the payment process is 
complete, the order delivery system (44) connects to the merchant's terminal (50) 
(1732) in the store and transmits the order (1734) and payment authorization. In 
an alternative embodiment, the order delivery system (44) can connect to and 
transmit the order through an integrated POS system (50) or a fax machine. 
Once the order has been transmitted, the merchant employee confirms (1736) 
the receipt of the order. The confirmation is transmitted through the order 
delivery system (44) to the transaction manager (10), which locks down the 
transaction (1738) and makes the required ledger (32) and log entries in the data 
warehouse (38). The merchant employee fulfills the order (1740) and the 
customer picks up the order (1742). 

First Time Customer Order and Payment 

When a customer is identified as a first time user (1714) the customer initiates 
the creation of an RO account by selecting and editing items, options and 
modifiers for their initial order (1780). The order information is transmitted 
through the customer access gateway (42) and passed to the transaction manger 



61 



(10), which verifies (1782) through the specific store information directory (36) 
that the items, options and modifiers in the order correspond to the offerings at 
that location. If not, the customer is asked to edit the order. 

5 The customer is given the option to create an RO customer account (28) (1784). 
Altematively, customer can choose to simply place an order without creating an 
account. In this case the order delivery system (44) connects to the terminal 
(50), POS (50) or fax at the merchant location and transmits the order to the 
store (1786). The merchant employee can confirm the receipt of order (1787) if 
10 required. The customer then proceeds to the store, makes the payment In a 
;;5 conventional manner, and picks up their order (1 788). 

\'f: 

ui If the customeSr wishes to establish an RO account they can save their initial 

?! order as a preference (1790) for convenient ordering in the future. The 

4- 

^ 15 transaction manager (10) saves the order preference information in the customer 

i°l account (28). The payment engine then computes the price, tax, tip and service 

0 fees (1 792) for the order. The customer is given the opportunity (1 800) to enter a 

O promotion code or promotional account number (1802). Once the code or 
account number is entered the payment engine (12) credits the customer's 

20 payment (1804). 

The customer is asked if they wish to pay with cash (1820). If so, the RO system 
transmits (1830) the order through the order delivery system (44) to the merchant 
IT equipment (50), where an employee can confimi (1826) the order if required. 
25 The printed or displayed order includes an indicator that payment must be taken 
before the order is fulfilled. The customer then proceeds to the store (1828), 
pays the employee at the POS (1828) and the employee fulfils the order (1850). 
In the case of customer payment at the POS no payment account information 
needs to be collect and a payment account does not need to be activated. 

30 
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The customer is asked if tliey wisli to create a payment account online (1822). In 
this case, the customer's payment account is established following the process 
shown in Figure 2A and 2B (1806). The order delivery system (44) transmits the 
order and request to authenticate the customer (1808) to the merchant terminal 
5 (50) or POS system. If required, a merchant employee confirms (1810) the 
receipt of the order. When the customer arrives at the store the merchant 
employee verifies the customer identity and activates their account following the 
process shown in Figure 4A, 4B, 4C, and 4D (1 81 2). Once the payment account 
is activated, the merchant temiinal transmits the confirmation through the order 
5 10 delivery system (44) to the security manager (18), which activates the account 
:i (28). The transaction manager (10) locks down the transaction (1814) and 
'5 makes the necessary ledger (32) and log entries in the data warehouse (38). 
il The merchant employee then fulfills the customer's order (1850). 
■I* 

h 15 The customer can take the option of both creating and activating an electronic 
IS payment account at the merchant's store location. This process has the clear 
If advantage of minimizing the amount of infomnatlon that must be collected 
Sj remotely through manual entry. Once the customer selects this option, the RO 
system transmits (1830) the order through the order delivery system (44) to the 
20 merchant IT equipment (50), where a merchant employee confirms (1830 it, If 
required. The customer then proceeds to the merchant's store location (1834) 
and creates (1836) a payment account using the process shown in Figure 3A and 
3B The customer's identity is verified and the payment account activated (1838) 
using the process shown in Figure 4A, 48, 4C, and 4D. The RO system signals 
25 the activation of the account to the merchant IT equipment (50) and locks down 
the transaction (1840). The merchant employee then fulfills (1850) the 
customer's order. 

It will be understood that the same processes described in this section can use 
30 data connections (rather than a telephone connection) as an alternative; only the 
format of the user interface is different. 
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INITIAL OFFER PROCESS 



To promote use of the remote ordering service, first time customers may be 
5 offered one or more initial promotional offers for trying the remote ordering 
service. These promotions are offered without the need for a customer to enter 
payment account information or any identity infonnation, thus speeding the 
process for the first time user and limiting the customer's risk and obligations. 
Once the customer has seen the value of the service, they can signup for the 
K 10 different levels of regular ordering and payment account capabilities. The basic 

0 order and fulfillment process follows the general flow already discussed in this 
\4 documents, in for example Figures 6 and 7. It will be clear to those skilled in the 
W art, that the same process can be followed using a data interface such as a Short 
1= Message Service (SMS), an IM system, the World Wide Web or two-way pagers. 
\n 15 

W An offer process can also be used to remove the burden of manually entering 

1 certain customer account (28) infonnation. The customer account can be pre- 
M populated using the same marketing databases (58) (or complementary 

databases) used to create and distribute the offers. 

20 

No Obligation Introduction 

The RO system supports a no-obligation introductory offer to walk-in customers 
at the merchant's location. This method does not require the advanced 

25 distribution of coupons or other information. When the customer arrives at the 
merchant's location they connect with their wireless access device (52) to the 
remote order system through the customer access gateway (42). Depending on 
the type of connection, the customer access gateway will capture the customer's 
telephone number (usually using ANI), data device ID or email address. As an 

30 optional security measure the customer may be asked for to enter an identifier to 
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use when picking up tlieir order. Minimal identifier information is collected to 
l<eep the process as anonymous as possible. 

Once connected the customer enters their order. Orders can be placed in a 
5 number of ways including at least the following: 

1 . Selecting items of choice from numbers shown on the merchant's menu 
board typically using an Interactive Voice Response (IVR) system, 

10 2. selecting products by number from a printed brochure typically using an 
IVR system, 

O 3. selecting items by stating their names using an Automatic Speech 

0 Recognition (ASR) system, and 

¥i 15 

"i 4. browsing an on-line product catalog using either a data interface such as 

y the World Wide Web, using either IVR or ASR methods or the sel^service 

1 kiosk (50). 

m 20 It will be clear to those skilled in the art that a combination of the above methods 

ij can be used. It will also be clear that the above techniques can be used for 

p subsequent orders as well. 

The order is transmitted through the customer access gateway (42) to the 
25 transaction manager (10). The transaction manager verifies that this is an initial 
order by querying the telephone numbers of other identifiers stored in the 
customer account (28). The transaction manager verifies that the items, options 
and modifiers selected are available at that store location by querying the 
location specific store information directory (36). If there is an error the customer 
30 is asked to edit their order. The transaction manager then passes the order to 
the merchant terminal (50) through the order delivery system (44) where it is 
printed or displayed by the merchant employee. 

The first time customer picks up the order or has it delivered in the usual manner 
35 previously described using the telephone number or device ID as an identifier.. 
Pickup can be in the store, at the curb or in a drive through. 
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The transaction manager (10) creates a provisional customer account (28) with 
the identifier and the Initial order. This Infomnation will be used when the 
customer wishes to establish some type of regular account. The transaction 
5 manager creates required entries in the merchant account (30), ledgers (32) and 
logs in the data warehouse (38) for use in settlement of the promotional 
expenses with the merchant location. 



Promotional Payment Accounts 



i^' ii 



10 



In an alternative embodiment, a first time customer uses a one-time use payment 
account to place an initial order. In this case the order processes discussed 
above and shown in Figures 6 and 7 are followed, with the exception that the 
promotional payment account number is used for an electronic payment (Instead 

15 of the customer's actual debit or credit account number). The promotional 
payment account uses the familiar 16-digit fonnat used for credit and debit 
accounts but with the Bank Identification Number (BIN) or other coding set to 
indicate this is a promotional account. The payment engine (12) or payment 
switch (14) recognizes that the payment is using a promotional account, in which 

20 case the customer will not be asked for typical payment account information, 
such as account holder name, address, etc. 



The first time customer picks up the order or has it delivered In the usual manner 
previously described using the telephone number, a device ID or an identifier 
25 selected by the customer as an identifier. Pickup can be in the store, at the curb 
or In a drive through. 

The transaction manager (10) creates a substantially anonymous provisional 
customer account (28) with the identifier and the initial order. This information 
30 will be used when the customer wishes to establish some type of regular 
account. The transaction manager creates entries in the merchant account (30), 
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ledgers (32) and logs In the data warehouse (38) for use in settlement of the 
promotional expenses with the merchant location. 

It will be clear to those skilled in the art, that the process discussed in this section 
5 can use other types of promotional codes and that gathering payment account 
information is not required. 

Communication of Promotion Codes and Accounts 

U 10 Prospective customers can receive trial promotional codes or payment account 

S; numbers in a variety of ways. These numbers can be posted at the merchants 

I^f store location, can be available on printed brochures available at store locations 

U| or other locations, or displayed in print or electronic media advertisements. 

k 

'I 15 In the preferred embodiment existing customers distribute the promotional codes 
ill or payment account numbers. The customers connect their access devices (52) 
'if to the customer access gateway (42). Customers enter contact information for 

CI people they know, whom they believe will be interested in the service. The 

contact information can include mailing address, email addresses or telephone 
20 numbers. The transaction manager (10) makes entries into the customer 
accounts (28) of the contact information each existing customer has supplied. 
The transaction manager then creates messages containing the promotional 
codes or payment account numbers, which are transmitted (via mail, email, IM, 
SMS, or voice mail) to the prospective customers through the customer access 
25 gateway (42). When prospective customers respond to the offer and enter the 
codes the payment manger queries the customer accounts to determine who 
referred the prospect and adds promotional credit to that customer's promotional 
account. The referring customer will be notified through the customer access 
gateway of the promotional value they have earned. This notification can be 
30 done in real-time when the credit is earned, or the next time the customer 
connects to the system for some other purpose. 
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In another embodiment, first time customers mal^e tlieir first contact with the 
customer access gateway (42) using a promotional telephone number or 
Universal Resource Locator (URL). Using this type of special connecfion 
5 eliminates the need for the customer to remember or enter promotional codes or 
payment account numbers all together. 

Promotional Coupons 

10 The RO system provides methods for customers to rapidly create accounts using 
is paper-based coupons. This method reduces to an absolute minimum the amount 
■ff of information that either the customer or the merchant needs to collect and 
W enter. The merchant distributes the coupons using targeted marketing methods. 
!|; Suitable targeted marketing direct mail methods for distributing coupons and 
;k 15 introductory ofl'ers to customers most likely to respond to them are well know. 
Ml The distributed coupons contain information on the service and state an 
j= introductory promotional offer the prospective customer can take advantage of. 

I! The coupons include coded information on the promotional offer and promotional 

code. In addition, the coding can include customer specific information derived 
20 from marketing databases (58) including name, address, email address, and 

telephone number. 

When the customer arrives at the merchant's location, they present the coupon to 
the merchant employee who scans the coupon using suitable peripherals 
25 attached to the merchant IT equipment (50). Alternatively, the customer can scan 
the infomiation at the self-service kiosk (50). In this case, the customer enters an 
identifier. 

The scanned information is transmitted through the order delivery system (44) to 
30 the transaction manger (10). The transaction manager creates a new customer 
account (28) entry using the information coded on the coupon. The promotional 
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information coded on tlie coupon is passed to tlie payment engine. The 
transaction manager (10) transmits the confirmation of the account creation 
through the order delivery system (44) to the merchant terminal (50) where It is 
displayed or printed. The merchant employee asks the customer for a telephone 
5 number, email, or user name, which the employee or the customer then enters 
into the merchant terminal (50). The identifier information is transmitted through 
the order delivery system (44) to the transaction manager (10), which adds the 
information to the customer account (28) (if this has not already been done). 
Once the customer account has been established the customer can place an 
!f 10 order using any of the methods discussed in this document. The payment engine 
i3 (12) applies the promotional discount and processes the payment using any of 
?! the methods discussed in this documents. If required, payment account 
Ul information can be collected manually or electronically with the merchant terminal 
1= (50) or self-service kiosk as has already been described. Once the order has 
15 been entered and payment processed, the transaction manager (1 0) transmits an 
authorization through the order delivery system (44) the merchant terminal (50). 
ii The merchant employee then fulfills the customer's order. 

ill 

Most any paper-based coding and scanning technology can be employed. 

20 Suitable coding and scanning technology include bar codes read with bar code 
scanners, printed characters read with an optical character recognition 
peripheral, or magnetic ink read with a magnetic ink scanners (such as are used 
for check draft capture). In an altemative embodiment, the paper coupon can be 
faxed to the remote order system, where the order delivery system (44) reads the 

25 encoded information and transmits it to the transaction manager (1 0). 

In an alternative embodiment the coded coupon is presented to the customer 
electronically. The electronic coupons can be distributed using a suitable targeted 
email database (58) for example. Suitable delivery methods include an (html) 
30 email or a customized web page. The electronic documents is printed by the 
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minimum amount of personal information along with payment account 
infomiation, and including a shared secret. The merchant subsequently presents 
a customer contract to the customer for signing when the customer attends at the 
POS for order fulfillment. This also provides an opportunity for the merchant to 
5 authenticate the customer and to allow the customer and its associated payment 
account to be activated. Authentication may be by verifying photo identification, 
requiring production of the credit or other card used for payment, or by some 
other means. 

10 Electronic generation of a customer contract on the merchant terminal or POS 
lij system (50) under control of the RO system is generally triggered by the 

Oil customer's initial use an electronic payment account to pay for an order with the 

i .1 merchant. When the customer attends at the POS to receive fulfillment of this 

'i order, the shared secret is exchanged between the merchant and customer using 
^ 15 the terminal or POS system to complete the payment transaction. Once 

established and verified, the security manager 18 uses the shared secret 

information as a rapid way to verify the customer's identity as required for 
iS electronic payment transactions. For example, the customer can be allowed to 

place orders, pay for them with a stored value account and have them fulfilled 
20 without entering the shared secret information, but may be required to use the 

shared secret information for direct payments or electronically funding the stored 

value account. 

25 The present invention provides for the use of a wide variety of shared secret 
information and electronic security credentials that are suitable for authentication 
of the customer during recurring payment transactions. For every transaction the 
security manager (18) authenticates the customer before the transaction is 
allowed to proceed. The security manager uses a series of security protocol 

30 adaptors to support a variety of authentication methods and customer interface 
devices 52, all accessed through the customer access gateway 42. Those skilled 
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in the art will be familiar with current and emerging methods used to collect and 
process shared secret infomnation in the payment industry. 

In general, passwords, Including Personal Identification Numbers (PIN), can be 
5 entered as alphanumeric characters into an Intemet terminal device (52) 
(connected to the customer access gateway 42), payment terminal or POS 
terminal (connected to the order delivery system 44), or can be entered into a 
telephone (connected through the customer access gateway 42) and decoded 
using an Interactive Voice Response (IVR) or spoken and decoded with an 
10 Automatic Speech Recognition system. 

;3I Alternatively, electronic security credentials can be used. These credentials can 
\d use symmetric or non-symmetric Public Key Infrastructure (PKI), a hash of an 
!! account number or other account identifier with a PIN or password, or symmetric 

15 or asymmetric secret key cryptography. These credentials can be contained 
Ul within various types of customer controlled electronic devices (52), including 
If wired and wireless Internet devices, wired or wireless telephone devices, Radio 
C| Frequency Identification (RFID) devices, magnetic cards, or smart cards. These 

^ electronic credentials typically require the customer to enter a password or PIN to 

20 complete the authorization. In these situations, authorization is based on the 
combination of something the customer possesses and something the customer 
knows. 

Remote Pavment Account Creation 

25 

Customers can establish an electronic payment account within the customer 
account (28) remotely using a variety of interface devices including wireless or 
wired Internet devices or wireless or wired telephones. This can occur upon 
initially establishing a customer account, or it can occur some time after the 
30 customer account has been established. This electronic payment account can be 
used to pay for goods and services directly or to fund a stored value account. 
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The payment account information is stored in the customer account (28). A flow 
chart of the basic process is shown in Figure 2A and 2B. Figs. 2A and 2B 
contemplate the remote establishment of a payment account either upon initial 
establishment of the customer account or at some later time after the customer 
5 account has been established. The alternative process, wherein the payment 
account is created (and information captured) at the merchant's point of sale is 
described in the next section and is shown in Figs. 3A and 3B. 

Referring to Fig. 2A and 28, the customer initiates the account creation by 
Ufc 10 connecting through the customer access gateway (42), entering payment 

2 account information (1000) into their interface device (52), which transmits the 
Si information to the RO system via the customer access gateway (42). Ideally a 
iji secure connection (i.e. SSL or similar technology) is used for this transmission, 
f I Suitable payment accounts include credit accounts and debit accounts (including 

15 Electronic Funds Transfer or EFT, and Automatic Clearing House or ACH). 

3 In one embodiment of the invention, (shown in figure 3A and SB) the customer's 
0 payment account information is captured at the POS on the merchant's terminal 
^ (50) from a magnetic of smart card or check draft when the customer attends at 

20 the merchant's location to activate the account and pickup their order. This 
alternative alleviates the customer of the burden of conrectly entering payment 
account information. According to this embodiment, the customer account may 
be provisionally created when the new customer remotely places the initial order. 
The provision of a customer identifier is contemplated so that the order may be 

25 matched to the individual upon the individual's attendance at the point of sale. 
The provisional creation of a customer account allows the remote ordering 
system to process the order and to deliver the order to the merchant point of 
sale. Upon the customer's attendance at the merchant's point of sale to receive 
order fulfillment, the relevant payment account information is electronically 

30 captured by the merchant's terminal (for example while processing payment from 
the customer's credit card). 
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Once the customer has supplied payment account information, the RO system 
then screens the account information for fraud (1002). The security manager 
(18) uses either internal (34) or external databases and processing capability to 
5 apply credit scoring, negative account matching, fraud profiling and other fraud 
screening methods to rate the account as worthy or not. If the account 
information does not meet the merchant's or processor's minimum criteria the 
payment account establishment process will generally be terminated. 

Q 10 Once the account has been scored for fraud (1002), the RO system connects 
9 (1004) to the appropriate payment processor (56) through the payment switch 

%l (14) and requests an authorization. Depending on the payment type this 

Ui 

m authorization process may be real-time or batch. When real-time processing is 

t^' employed the RO system waits for the authorization to proceed with the account 

Q 15 setup. When batch processing is employed the RO system will continue 
processing the account setup but may not activate the account until an 

ff authorization is received. With a batch process the authorization may, for 

m example, be processed using an ACH test batch. 

20 In an alternative embodiment the credit scoring and fraud screening is performed 
by the acquiring payment processor (56). In this case the security manager (18) 
will authorize the activation of the account (or not) based on the results of this 
fraud check. 

25 If the payment processor (56) does not return an authorization (1006) to the 
payment switch (14) the customer access gateway (42) will connect to the 
customers interface device (52) and inform them of the authorization failure 
(1008). If the customer wishes to try another payment account (1010) and if the 
limit of attempts (1012) has not been reached the payment account creation 

30 process will be retried. The number of tries allowed is determined by the rules of 
the processor and the merchant. 
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Once the electronic payment account has been established, the security 
manager (18) requests that the customer inputs (1013) some type of shared 
secret Information through the customer access gateway (42) (in the case of 
5 remote account creation) and the customer enters this infomnation (1014) into the 
their access device (52) which transmits It to the RO system through the 
customer access gateway. The customer is then asked (1015) to reenter this 
information as a verification. The customer reenters the information (1016) Into 
their Interface device, which transmits It to the RO system through the customer 
10 access gateway. The security manager (1 8) verifies the agreement of the shared 
p secret information (1018). If there Is not agreement the security manager will 
!J! request through the customer access gateway that the customer Input the shared 
W secret infomnation again If there have not been too many tries (1020). The 
|; number of tries allowed Is determined by the rules of the processor and the 
ILi 15 merchant. 
W 

in the case of In-store account creation. It will be appreciated that the shared 

P. secret Information can be effectively exchanged in person when the customer 

ill 

attends to the merchant's location using the merchant's IT equipment (50). 

20 

In an alternative to direct exchange of shared secret information, the customer's 
electronic credential may be embedded in a wireless access device (52), which 
connects to the RO system through the customer access gateway (42) using 
either a wide area wireless network or a local area wireless base-station located 

25 at the store. The process used for establishing the payment account follows a 
nearly identical flow to the one already described in this section, but with the 
electronic credential being used as an alternative to the shared secret 
information. The electronic credential typically will Itself require use of some 
shared secret information. In this embodiment, the customer is usually 

30 authenticated by an external authority, which can Include a PKI Certificate 
Authority (CA) or an authentication authority using secret key cryptography. This 
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authority is operated by a number of entities Including, an Internet service 
provider, a telecommunications provider, a financial institution or payment 
processor or a third party certification authority. The payment account being 
used can be held and processed by the same certification authority. In this 
5 alternative embodiment, the security manager (18) (through security protocol 
adaptors) and the payment engine (12) (through the payment switch) interface to 
the certification authority or external processor (56), through the payment switch 
(14). 

I.,., 10 Altematively, the security manager (18) asks customers using electronic security 
CI credentials for shared secret information. The customer enters this information 
ff| into their access device (52) and it is transmitted to the security manager through 
!i the customer access gateway (42). This shared secret information is used later 
f ^ for account activation in cases where the authentication of the customer or the 
J 15 certification authority is not verifiable or where the service provider for the 
!'! security credential Is not a certification authority (that Is, they issue secure 
SI credentials, but cannot certify the authenticity of the customer). Most Certificate 
3| Authorities in operation today fall into this category. That is, they only issue and 

• y authenticate certificates, but are not certification authorities who can validate the 
20 customer's identity. Alternately, this shared secret information can be used to 
activate the customer's account at the point of sale without the need for the 
customer or the RO system to reconnect to the certification authority. 

Once the shared secret information and/or security credentials have been 
25 validated, the payment account is activated. 

In Store Pavment Account Creation 

In one embodiment of the Invention, customers establish an electronic payment 
30 account within the customer account (28) while attending at the merchant's store 
location after having placed at least an Initial order through the RO system. This 
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process can be performed at any time the customer wishes to add electronic 
payment options to their customer account (28). This in-store activity can be 
done using a variety of interface devices including dedicated payment terminals 
(50) and integrated POS systems (50) or a self-service kiosk (50) at the 

5 merchant's store location. While establishing an electronic payment account at a 
store location is typically done while the customer is placing or picking up an 
order, including an initial order, it can be done at any time. The electronic 
payment account can be used to pay for goods and services directly or to fund a 
stored value account. A flow chart of the basic process Is shown In Figure 3A 

10 and 3B. 

The customer or merchant employee initiates the payment account creation by 
capturing payment account information (1040) into the payment terminal, 
integrated POS system or self-service kiosk (all merchant IT equipment 50). In 

15 the preferred embodiment, the customer or merchant employee will electronically 
capture the payment account Information. This capture can involve swiping a 
magnetic card, reading information from a smart card, capturing account 
information from a check draft, etc. Alternatively, this information can be 
captured by manually entry. Suitable payment accounts include credit accounts 

20 and debit accounts (including Electronic Funds Transfer or EFT and Automatic 
Clearing House or ACH). In either case, the infomnation is transmitted from the 
merchant's IT equipment (50) to the RO system via the order delivery system 
(44). 

25 The RO system then screens the account information for fraud (1042). The 
security manager (18) uses either internal (34) or external databases and 
processing capability to apply credit scoring, negative account matching, fraud 
profiling and other fraud screening methods to rate the account as worthy or not. 
If the account information does not meet the merchant's or processor's minimum 

30 criteria the account creation process will generally be terminated. Those skilled 
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in the art will be familiar with established and emerging payment industry practice 
for fraud screening. 

Once the account has been scored for fraud (1042), the RO system connects 
5 (1044) to the appropriate payment processor (56) through the payment switch 
(14) and requests an authorization. Depending on the payment type this 
authorization process may be real-time or batch. When real-time processing is 
employed the RO system waits for the authorization to proceed with the account 
setup. When batch processing is employed the RO system will continue 
10 processing the account setup but may not activate the account until an 
13 authorization is received. With a batch process the authorization may, for 
S| example, be processed using an ACH test batch. 

ijl In an alternative embodiment the credit scoring and fraud screening is performed 
T- 15 by the acquiring payment processor (56). In this case the security manager (18) 
CI will authorize the activation of the account (or not) based on the results of this 
r\ fraud check. 

ilf If the payment processor (56) does not retum an authorization (1046) to the 

20 payment switch (14) the customer access gateway (42) will connect to the 
customer's access device (52) and inforni them of the authorization failure 
(1048). If the customer wishes to try another payment account (1050) and if the 
limit of attempts (1052) has not been reached the payment account creation 
process will be retried. The number of tries allowed is determined by the rules of 
25 the processor and the merchant. 



Once the electronic payment account has been established within the customer 
account (28), the security manager (18) requests (1054) that the customer inputs 
some type of shared secret infonnation (1056). The customer is then asked 
30 (1058) to reenter (1060) this information as a verification. The request and the 
shared secret information are transmitted between the RO system and the 
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terminal (50) at the merchant's location though the order delivery system (44). 
The requests are displayed and the shared secret information entered using a 
dedicated payment terminal, an integrated POS or the self-service kiosk 
(collectively, the merchant IT equipment 50). The security manager verifies the 
5 agreement of the shared secret information (1062). If there is not agreement the 
security manager will request through the order delivery system (44) that the 
customer input the shared secret information again if there have not been too 
many tries (1064). The number of tries allowed is detemnined by the rules of the 
processor and the merchant. 

^ 10 

In an alternative embodiment, the customer's electronic credential is embedded 
fi in a wireless access device (52), which connects to the RO system through the 
Ul customer access gateway using either a wide area wireless network or a local 
area wireless base-station located at the store. The process used for 
% 15 establishing the payment account follows a nearly identical process flow to the 
3 one already described in this section, but with the electronic credential being 

S used as an alternative to the shared secret infomnation. The electronic credential 
Q typically will require use of some shared secret information. In this embodiment, 

the customer is usually authenticated by an external authority, which can Include 
20 a PKI Certificate Authority (CA) or an authentication authority using secret key 
cryptography. This authority is operated by a number of entities including, an 
Internet Service Provider (ISP), a telecommunications provider, a Financial 
Institution (Fl) or payment processor or a third party certification authority. The 
payment account being used can be held and processed by the same 
25 certification authority. In this alternative embodiment, the security manager (18) 
(through security protocol adaptors) and the payment engine (12) (through the 
payment switch 14) interface to the certification authority or external processor. 
Requests for Information to merchant employees and responses displayed for 
merchant employees are communicated to the terminal (50) at the merchant 
30 location through the order delivery system. 
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In yet another alternative embodiment, the customer can authenticate himself or 
herself with the electronic credential remotely and entering shared secret 
infomiation into the RO system interface at the same time (as is shown in Figure 
2A and 2B). The customer then uses the shared secret information for account 
5 activation when attending the merchant's location to authenticate they are the 
same person using the certificate. This method has the advantage of not 
requiring the customer to take the device (which may not be portable) to the 
merchant's location. 

, 10 Account Activation and Verification of Customer Identity 

:..'!«?: 

ill Once the customer has completed the ordering process the remote ordenng 

^ system transmits the order to the IT equipment (50) at the merchant's location. If 

■P the customer wishes to activate an electronic payment account this is preferably 

J 15 done before the customer's order is fulfilled. At the same time the order is 

H printed or displayed, a contract or payment service agreement is printed on the 

Ml 

g mercliant terminal or POS system (50). Typically one copy of the contract will be 

S| printed for the customer's records and one copy of the merchant's records. 
^ Merchant employees will have the customer sign the contract and verify the 

20 customer's identity as required. Once the customer has been authenticated (for 
example by verifying the customer's identity using photo identification) and a 
signature captured on the service contract, the merchant and the customer have 
a secure basis for subsequent transactions with agreed to terms and conditions. 
In general the shared secret information, possibly combined with a security 
25 credential, is then used for future payment transactions. 

The basic flow for the payment account activation process is shown in Figure 4A, 
4B, 4C and 4D. This process flow is mediated by the security manager (18), 
which applies to a variety of authentication protocols using the appropriate 
30 authentication protocol adaptors. Usually, this process is perfomried when the 
customer arrives at the merchant's store location to pick up their initial remote 
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order or an electronic order placed from the store. In this case the order is 
prepared based on an open payment authorization, which is closed when the 
customer is authenticated and the account activated. 



5 The order and contract are transmitted through the order delivery system (44) 
over a wired or wireless data network to a terminal or POS system (50) at the 
merchant's location. The order data can be displayed on the terminal or 
presented in printed form (printed by the terminal or POS system) or both. The 
order data will Include infonnation to identify the customer, typically in the fomn of 

10 a telephone number or device ID. Altematively a user name or alias can be 

! •■ 

□ used, but is not required for the invention. Other identifying information such as a 

S vehicle description or license number can also be displayed. Once the order is 

received the merchant's employees can begin preparing it. The paper contract 
5i will typically include the customer's legal name and will have a signature line. 
15 The customer can identify himself or herself to the merchant's employees by their 

if 

O telephone number, device ID, user name, legal name or alias, 

T C S 

fi; The printed or displayed information includes the request to verify the customer's 

ill identification, verify shared secret information or security credentials, or to 
20 capture a customer signature (1082) as required for the payment type being 
used. When the customer anrives at the store (1084), the customer is presented 
with a summary service agreement contract (1085), and the need is determined 
(1086) to verify the customer's security credential or shared secret information. 
The verification process can include checking of a photo ID, verification of ID 
25 number information (i.e. account or other numbers entered during account 
creation), and matching of signatures. 

If the customer is using a mobile wireless access device (52) as a security 
credential they connect (1088) to the RO system through the customer access 
30 gateway (42) and can then verify the shared secret information or security 
credential (1090) in the presence of the merchant employee. Alternatively, the 
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the event of a dispute with the customer (repudiation of a payment transaction) or 
suspected fraud. The printed contract document can be a full set of the terms 
and conditions or can be a summary. If a summary forni of the contract is used, 
the customer can receive a full copy on line (on World Wide Web or email), 
5 through the mail in printed form, or distributed in printed form by the merchant 
employee. 

If signature capture is not required the employee will request identification from 
the customer (1118). The customer provides identification (1120) and the 
10 merchant employee then verifies the identification (1 1 22). 

SI Once the customer's identity has been verified and a signature captured, as 

%l 

required, the employee enters (1 124) a verification code into the terminal or POS 
5 system (50). The temiinal or POS system transmits the verification code though 
15 the order delivery system (44) to the RO system (1 1 26) where it Is archived in the 
3 customer account (28) and the merchant account (30). At the same time digital 
5 signature information is transmitted if required. Once all information is logged in 
ijl the RO system, the RO system sends a final authorization (1128) for the open 

authorization through the order delivery system to the merchant terminal for 
20 display to the merchant employee. The RO system then records all information 
required (including security information) required for future payment transactions 
(1130). 

Capture of Payment Account Information at POS 

25 

In the preferred embodiment, the customer's payment account information can 
be captured at the point of sale during the account activation process. This 
process allows customers to create payment accounts without the need to 
actually enter the payment account information (account holder name, account 
30 number, routing numbers, etc.). This process saves customers time and also 
prevents errors arising from manual data entry. In addition, the level of fraud will 
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customer can enter (1092) the shared secret information into the merchant's 
terminal (50) in the presence of the merchant employee. In this case, the shared 
secret information is transmitted from the temiinal to the RO system through the 
order delivery system (44). In either case, the shared secret information or 

5 security credential is verified (1094) and a confirmation is transmitted through the 
order delivery system to the merchant terminal where a confirmation is displayed 
(1104) for the merchant employee. Optionally, the merchant employee can 
transmit a confimiation of the authentication process to the customer's wireless 
device, which gives the customer assurance that the merchant connection was 

10 authentic, if a wireless device is used as an authentication credential. 

5 If the confirmation of the shared secret information or security credential fails 
(1094) the customer will be informed of the failure (1096) either through the 
•if merchant terminal (50) or their wireless access device (52). If the customer 

4' 15 wishes to try again (1098) the customer reenters the shared secret infomnation or 
Si electronic security credential (1100). If there have not been too many attempts 
S by the customer (1102), the RO system will verify (or not) the shared secret 
■I' information or security credential (1094). The number of attempts allowed is 

jfi determined by the merchant and processor's business rules. 
20 

If signature capture is required (1 106) the employee will ask (1 108) the customer 
for a signature and the customer provides the signature (1110). The signature 
can be captured on a paper fomi produced by a printer attached to the merchant 
terminal or POS (50). Alternatively, if the merchant IT equipment (50) is 

25 equipped with the proper peripherals, the customer's signature can be captured 
by electronic means, either directly (using an electronic tablet and stylist for 
example) or by scanning the paper contract. The digitally captured signature is 
then transmitted through the order delivery system (44) to the RO system (1112) 
where it is achieved in the data warehouse (38). The merchant employee will 

30 then verify the customer's signature and identification (1114). Either the paper 
form or the digital signature are archived (1116) in a manner allowing retrieval in 
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customer and brought to the merchant's store location. The process of creating 
the customer account then follows the process already described. 

introductory Offers with Pre-Populated Accounts 

5 

The RO system provides methods to create a customer account (28) using 
information that is pre-populated Into that database. This method reduces to an 
absolute minimum the amount of information that either the customer or the 
merchant needs to collect and enter. The transaction manager (10) loads the 
i^^, 10 information in batch to the customer account (28) from marketing databases (58) 
if or other databases (58) containing likely prospects such as customer lists of the 
iSI merchant or related merchants. The information read by the transaction manager 
(10) from these databases (58) can include, name, address, telephone number, 
email address, etc. 

. 15 

H The same databases (58) used to populate the account or separate specialized 

CI databases (58) are used to address the offer messages for transmission to 

if r 

gl prospective customers. Suitable transmission means include paging message, 

email, SMS message or IM message. These messages will generally contain 

20 information on the service and an introductory promotional offer to the customer. 
The message contains a unique identifier that is used to identify the customer 
during account creation. When the customer receives one of these messages 
they can electronically initiate creation of an account, but without the need to 
enter the information already available. The customer uses their access device 

25 (52) to connect to the system through the customer access gateway (42). Once 
connected, and if it cannot be done automatically, the customer enters the unique 
identified, which the transaction manager (10) uses to identify the customer 
account (28) Infonnation used to create the new account. With a telephone 
connection the customer telephone number is automatically collected by the 

30 customer access gateway (42) using the AN I or other available means. With a 
World Wide Web connection a unique URL (includes the unique identifier in the 
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URL) can be used to identify the customer. Either of these methods saves the 
customer the need to enter the unique identifier manually. Depending on the type 
of connection type and capability, the customer will be asked to enter an account 
name or alias. The identifier information is transmitted through the order delivery 
5 system (44) to the transaction manager (10), which adds the information to the 
customer account (28) and creates the required entries. Once the customer 
account has been established the customer can place an order using any of the 
methods discussed in this document. The payment engine (12) applies the 
promotional discount and processes the payment using any of the methods 
10 discussed in this documents. If required, payment account information can be 
O collected manually or electronically as has already been described in this 
:|! document. The rest of the process for account creation and activation will follow 

^ the processes already discussed in this document. 

f 15 Alternatively the unique identifier can be coded on a printed document or coded 
^3 in an electronic document that is printed by the customer. The same database 

lEi (58) used to populate accounts or a special purpose database (58) is used to 

;fj address these messages to the prospective customers. The messages are sent 

lil to the prospective customers based on these addresses. Interested customers 

20 take the printed documents to the merchant's location where the account is 
created using the process described in the previous section with the exception 
that customer specific information is available in the database (58) rather than 
scanned from the form. 

25 In an alternative embodiment the transaction manager (10) uses a real-time 
network connection to the databases (58). When a customer wishes to create an 
account the transaction manager queries the external databases (58) to retrieve 
the required infomiation. The transaction manager then places this infomiation 
into the customer account (28). The account creation process then follows the 

30 flow discussed in this section. 
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